Hubbry Logo
Runtime systemRuntime systemMain
Open search
Runtime system
Community hub
Runtime system
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Runtime system
Runtime system
Runtime system
View on Wikipedia
from Wikipedia

Program execution
General concepts
Types of code
Compilation strategies
Notable runtimes
Notable compilers & toolchains

In computer programming, a runtime system or runtime environment is a sub-system that exists in the computer where a program is created, as well as in the computers where the program is intended to be run. The name comes from the compile time and runtime division from compiled languages, which similarly distinguishes the computer processes involved in the creation of a program (compilation) and its execution in the target machine (the runtime).[1]

Most programming languages have some form of runtime system that provides an environment in which programs run. This environment may address a number of issues including the management of application memory, how the program accesses variables, mechanisms for passing parameters between procedures, interfacing with the operating system (OS), among others. The compiler makes assumptions depending on the specific runtime system to generate correct code. Typically the runtime system will have some responsibility for setting up and managing the stack and heap, and may include features such as garbage collection, threads or other dynamic features built into the language.[1]

Overview

[edit]

Every programming language specifies an execution model, and many implement at least part of that model in a runtime system. One possible definition of runtime system behavior, among others, is "any behavior not directly attributable to the program itself". This definition includes putting parameters onto the stack before function calls, parallel execution of related behaviors, and disk I/O.

By this definition, essentially every language has a runtime system, including compiled languages, interpreted languages, and embedded domain-specific languages. Even API-invoked standalone execution models, such as Pthreads (POSIX threads), have a runtime system that implements the execution model's behavior.

Most scholarly papers on runtime systems focus on the implementation details of parallel runtime systems. A notable example of a parallel runtime system is Cilk, a popular parallel programming model.[2] The proto-runtime toolkit was created to simplify the creation of parallel runtime systems.[3]

In addition to execution model behavior, a runtime system may also perform support services such as type checking, debugging, or code generation and optimization.[4]

comparison between concepts similar to runtime system
Type Description Examples
Runtime environment Software platform that provides an environment for executing code Node.js, .NET Framework
Engine Component of a runtime environment that executes code by compiling or interpreting it JavaScript engine in web browsers, Java Virtual Machine
Interpreter Type of engine that reads and executes code line by line, without compiling the entire program beforehand CPython interpreter, Ruby MRI, JavaScript (in some cases)
JIT interpreter Type of interpreter that dynamically compiles code into machine instructions at runtime, optimizing the code for faster execution V8, PyPy interpreter

Relation to runtime environments

[edit]

The runtime system is also the gateway through which a running program interacts with the runtime environment. The runtime environment includes not only accessible state values, but also active entities with which the program can interact during execution. For example, environment variables are features of many operating systems, and are part of the runtime environment; a running program can access them via the runtime system. Likewise, hardware devices such as disks or DVD drives are active entities that a program can interact with via a runtime system.

One unique application of a runtime environment is its use within an operating system that only allows it to run. In other words, from boot until power-down, the entire OS is dedicated to only the application(s) running within that runtime environment. Any other code that tries to run, or any failures in the application(s), will break the runtime environment. Breaking the runtime environment in turn breaks the OS, stopping all processing and requiring a reboot. If the boot is from read-only memory, a secure, single-mission system is created.

Examples of such directly bundled runtime systems include:

Examples

[edit]

The runtime system of the C language is a particular set of instructions inserted by the compiler into the executable image. Among other things, these instructions manage the process stack, create space for local variables, and copy function call parameters onto the top of the stack.

There are often no clear criteria for determining which language behaviors are part of the runtime system itself and which can be determined by any particular source program. For example, in C, the setup of the stack is part of the runtime system. It is not determined by the semantics of an individual program because the behavior is globally invariant: it holds over all executions. This systematic behavior implements the execution model of the language, as opposed to implementing semantics of the particular program (in which text is directly translated into code that computes results).

This separation between the semantics of a particular program and the runtime environment is reflected by the different ways of compiling a program: compiling source code to an object file that contains all the functions versus compiling an entire program to an executable binary. The object file will only contain assembly code relevant to the included functions, while the executable binary will contain additional code that implements the runtime environment. The object file, on one hand, may be missing information from the runtime environment that will be resolved by linking. On the other hand, the code in the object file still depends on assumptions in the runtime system; for example, a function may read parameters from a particular register or stack location, depending on the calling convention used by the runtime environment.

Another example is the case of using an application programming interface (API) to interact with a runtime system. The calls to that API look the same as calls to a regular software library, however at some point during the call the execution model changes. The runtime system implements an execution model different from that of the language the library is written in terms of. A person reading the code of a normal library would be able to understand the library's behavior by just knowing the language the library was written in. However, a person reading the code of the API that invokes a runtime system would not be able to understand the behavior of the API call just by knowing the language the call was written in. At some point, via some mechanism, the execution model stops being that of the language the call is written in and switches over to being the execution model implemented by the runtime system. For example, the trap instruction is one method of switching execution models. This difference is what distinguishes an API-invoked execution model, such as Pthreads, from a usual software library. Both Pthreads calls and software library calls are invoked via an API, but Pthreads behavior cannot be understood in terms of the language of the call. Rather, Pthreads calls bring into play an outside execution model, which is implemented by the Pthreads runtime system (this runtime system is often the OS kernel).

As an extreme example, the physical CPU itself can be viewed as an implementation of the runtime system of a specific assembly language. In this view, the execution model is implemented by the physical CPU and memory systems. As an analogy, runtime systems for higher-level languages are themselves implemented using some other languages. This creates a hierarchy of runtime systems, with the CPU itself—or actually its logic at the microcode layer or below—acting as the lowest-level runtime system.

Advanced features

[edit]

Some compiled or interpreted languages provide an interface that allows application code to interact directly with the runtime system. An example is the Thread class in the Java language. The class allows code (that is animated by one thread) to do things such as start and stop other threads. Normally, core aspects of a language's behavior such as task scheduling and resource management are not accessible in this fashion.

Higher-level behaviors implemented by a runtime system may include tasks such as drawing text on the screen or making an Internet connection. It is often the case that operating systems provide these kinds of behaviors as well, and when available, the runtime system is implemented as an abstraction layer that translates the invocation of the runtime system into an invocation of the operating system. This hides the complexity or variations in the services offered by different operating systems. This also implies that the OS kernel can itself be viewed as a runtime system, and that the set of OS calls that invoke OS behaviors may be viewed as interactions with a runtime system.

In the limit, the runtime system may provide services such as a P-code machine or virtual machine, that hide even the processor's instruction set. This is the approach followed by many interpreted languages such as AWK, and some languages like Java, which are meant to be compiled into some machine-independent intermediate representation code (such as bytecode). This arrangement simplifies the task of language implementation and its adaptation to different machines, and improves efficiency of sophisticated language features such as reflective programming. It also allows the same program to be executed on any machine without an explicit recompiling step, a feature that has become very important since the proliferation of the World Wide Web. To speed up execution, some runtime systems feature just-in-time compilation to machine code.

A modern aspect of runtime systems is parallel execution behaviors, such as the behaviors exhibited by mutex constructs in Pthreads and parallel section constructs in OpenMP. A runtime system with such parallel execution behaviors may be modularized according to the proto-runtime approach.

History

[edit]

Notable early examples of runtime systems are the interpreters for BASIC and Lisp. These environments also included a garbage collector. Forth is an early example of a language designed to be compiled into intermediate representation code; its runtime system was a virtual machine that interpreted that code. Another popular, if theoretical, example is Donald Knuth's MIX computer.

In C and later languages that supported dynamic memory allocation, the runtime system also included a library that managed the program's memory pool.

In the object-oriented programming languages, the runtime system was often also responsible for dynamic type checking and resolving method references.

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Runtime system

View on Grokipedia
from Grokipedia
A runtime system, also known as a runtime environment, is a that supports the execution of computer programs by providing essential services such as memory allocation, task scheduling, synchronization, and during program runtime. It acts as an intermediary between the application code and the underlying hardware or operating system, handling dynamic aspects of execution that compilers cannot fully resolve at . Runtime systems are fundamental to modern programming, enabling portability across different hardware platforms and simplifying development by abstracting low-level details like thread management and garbage collection. Key functions typically include monitoring program behavior for optimization and orchestrating concurrent activities. In contexts, they adapt dynamically to hardware status and application needs, mitigating issues like latency, contention, and overhead to improve and efficiency. Runtime systems vary by purpose and scope, with prominent types including language-specific runtimes that interpret or execute high-level code (e.g., the Runtime Environment, which manages memory, exceptions, and native method linking for Java applications), parallel processing runtimes like Cilk that handle multithreading and load balancing, and monitoring frameworks for . Examples also encompass the Python runtime, which supports dynamic typing, and runtimes that enable shared-memory parallelism on multicore systems. These systems have evolved significantly since the , driven by advances in parallel architectures and the need for energy-efficient execution in .

Fundamentals

Definition and Purpose

A (RTS), also known as a runtime environment, is a software layer that implements key aspects of a programming language's execution model, delivering essential services to programs during their execution. These services include allocation, , thread management, and dynamic linking, enabling the program to interact with underlying computing resources without direct exposure to hardware specifics. The primary purposes of an RTS are to facilitate portability across diverse hardware and operating systems by abstracting low-level implementation details, and to support language-specific constructs such as dynamic typing, where type information is resolved and enforced at execution time rather than during compilation. By handling these responsibilities, the RTS allows developers to focus on high-level logic while ensuring reliable and efficient program behavior in varied environments. In contrast to compile-time processes, which translate into form and resolve static elements like syntax and fixed dependencies, the RTS operates post-compilation to manage dynamic aspects of execution. For instance, it resolves unresolved symbols through mechanisms like of libraries and accommodates runtime behaviors such as polymorphic dispatch or conditional resource needs that cannot be predetermined statically. At a high level, the of an RTS positions it as an intermediary bridge between application code and the host operating system or hardware, orchestrating resource access, error recovery, and execution to maintain program integrity and . Runtime systems often incorporate or interface with virtual machines to simulate standardized execution contexts.

Core Components

A runtime system's core components form the foundational modules that enable the loading, execution, and of programs during runtime. The loader is responsible for reading code from storage, resolving dependencies, and placing it into for execution, ensuring that the program and its libraries are properly initialized before control is transferred to the application's . The scheduler manages the allocation of computational resources to threads or processes, determining the order and duration of their execution to optimize concurrency and responsiveness while coordinating with the underlying hardware. The allocator handles dynamic requests from the program, providing mechanisms to request, allocate, and deallocate heap space as needed during execution, often integrating with storage to prevent fragmentation and leaks. The exception handler detects runtime errors, propagates them up the call stack through unwinding, and invokes appropriate recovery or termination routines to maintain program integrity. These components interact seamlessly to support continuous program execution; for instance, the scheduler may invoke the allocator when creating new threads to secure necessary , while the loader collaborates with the scheduler to sequence the startup of multiple execution units. In error scenarios, the exception handler coordinates with the allocator to release resources during stack unwinding, preventing leaks, and signals the scheduler to pause or terminate affected threads. Such collaborations ensure that and error recovery occur without disrupting the overall execution flow. Runtime systems expose standard interfaces through APIs or hooks that allow applications to interact with these components, such as initialization entry points like main() or runtime-specific startup functions that configure the loader and scheduler before program logic begins. These interfaces provide hooks for custom extensions, enabling developers to register callbacks for events like memory allocation failures or thread scheduling adjustments. Minimal runtime systems, common in embedded environments, consist of basic components focused on essential execution support with limited overhead, such as a simple loader for bare-metal code and a lightweight scheduler for real-time constraints, often running without an underlying operating system. In contrast, full-featured runtime systems in high-level languages incorporate comprehensive implementations of all core components, supporting advanced and error handling to accommodate complex, portable applications across diverse hardware.

Conceptual Relations

Runtime Environment

The runtime environment constitutes the comprehensive execution context for a program, encompassing the runtime system (RTS), associated libraries, and the dedicated execution that collectively isolate and sustain program operation. This setup provides an abstract, application-centric habitat where code runs independently of underlying hardware variations, ensuring portability and controlled resource access. In managed languages, for instance, the Java Runtime Environment (JRE) integrates the (JVM), class libraries, and supporting tools to form this isolated , enabling execution without direct hardware interaction. Key features of the runtime environment include sandboxing mechanisms for security, enforcement of resource limits, and the incorporation of environment variables to modulate behavior. Sandboxing creates a protected boundary around the program's execution, restricting access to sensitive operations like modifications or network calls to mitigate risks from untrusted code, as seen in virtual machine-based environments where bytecode verification prevents malicious actions. Resource limits, such as configurable stack sizes and heap boundaries, prevent excessive consumption and ensure fair allocation. Environment variables, passed at startup, influence runtime decisions, such as selecting garbage collection algorithms or levels, thereby tailoring the execution without altering the source code. Distinct from the RTS itself—which primarily handles dynamic execution tasks like memory allocation and exception management—the runtime environment serves as the overarching habitat that embeds and extends the RTS, facilitating cross-platform consistency through standardized interfaces and virtualized execution. For example, the .NET runtime environment leverages the (CLR) within a broader framework that includes base class libraries and configuration settings, allowing applications to run uniformly across diverse hosts by abstracting platform-specific details. implementations commonly host this environment to enforce uniformity. Configuration of the runtime environment occurs through mechanisms like command-line flags for immediate adjustments (e.g., setting heap size via JVM options like -Xmx) or configuration files that define persistent parameters, such as quotas or library paths, enabling developers to optimize for specific deployment scenarios.

Operating System Integration

Runtime systems integrate with operating systems primarily through system calls, which serve as the primary interface for requesting kernel services such as (I/O) operations, file access, and signaling mechanisms. These system calls allow the runtime to proxy or wrap low-level OS interactions on behalf of applications, providing a layer of that simplifies while ensuring and isolation. For instance, when an application requires file I/O, the runtime intercepts the request and translates it into appropriate OS-specific invocations, handling details like buffering and error propagation to maintain consistency across executions. Runtime systems exhibit significant dependencies on the OS kernel for fundamental operations, including process creation, (IPC), and . The kernel manages process lifecycle events, such as forking or terminating processes, which the runtime relies upon to initialize execution contexts without direct hardware access. IPC primitives, like or , enable coordination between runtime-managed components and external processes, while hardware abstraction layers () shield the runtime from platform-specific details, allowing it to operate uniformly over diverse . These dependencies ensure that the runtime can leverage the OS's robust handling of concurrency and , such as in multi-threaded environments where kernel schedulers complement runtime components. A key challenge in runtime system design is achieving portability across different operating systems, stemming from variations in system call interfaces, such as the distinct syscall numbering and semantics between (using POSIX-compliant calls) and Windows (employing Win32 APIs). These differences can lead to compilation failures or runtime errors when porting code, as direct syscall invocations may not translate seamlessly. To mitigate this, runtime systems employ layers, such as portable wrappers or virtual syscall tables, that map platform-specific calls to a unified , reducing maintenance overhead and enabling cross-OS deployment without extensive rewrites. In hybrid models, runtime systems can partially supplant OS functions by implementing mechanisms in user space, exemplified by user-space threading where the runtime manages thread scheduling and context switching independently of the kernel. This approach offloads from the OS, improving and in high-throughput scenarios, as the runtime can threads without invoking costly kernel traps. Such models integrate with the OS only for heavyweight operations like true parallelism across cores, balancing efficiency with the need for kernel-mediated resource access.

Practical Examples

In Managed Languages

In managed languages, the (JVM) serves as a cornerstone runtime system, executing platform-independent compiled from through interpretation or just-in-time () compilation. The JVM handles interpretation by loading class files into and executing instructions via an interpreter or compiled native , ensuring portability across diverse hardware and operating systems. Class loading in the JVM involves a hierarchical system of class loaders, including the bootstrap loader for core classes and user-defined loaders for application-specific classes, which enforce isolation and at runtime. Additionally, the JVM incorporates a security manager that enforces a sandboxed execution environment, restricting access to system resources like file I/O or network connections based on policy files, thereby mitigating risks from untrusted . The .NET Common Language Runtime (CLR) provides a similar managed execution environment for languages like C# and Visual Basic .NET, processing intermediate language (IL) code generated by the compiler. The CLR supports IL execution through JIT compilation to native machine code, enabling efficient runtime performance while abstracting hardware differences. Assembly loading in the CLR occurs via the assembly loader, which resolves dependencies and loads managed modules into memory, supporting versioning and side-by-side execution of multiple assembly versions. App domains in the .NET Framework CLR offer logical isolation boundaries within a single process, facilitating security, reliability, and the ability to unload assemblies without terminating the application, which enhances modularity in enterprise scenarios. However, AppDomains are a legacy feature and were removed in .NET Core and later versions (unified .NET 5+); in modern .NET, isolation is typically achieved through separate processes, containers, or assembly-level boundaries. Both the JVM and CLR share key similarities in managed runtime features, such as automatic garbage collection for and bytecode/IL verification to ensure and prevent invalid operations before execution. The JVM's HotSpot implementation distinguishes itself with advanced optimization techniques, including tiered compilation that profiles hot code paths for aggressive inlining and to eliminate unnecessary allocations. A comparative analysis confirms that these systems exhibit comparable overall performance, with differences primarily in optimization strategies rather than fundamental capabilities. These runtime systems enable the "" paradigm by compiling to an intermediate form that the runtime interprets or compiles on target platforms, abstracting underlying differences in and OS while providing like garbage collection for developer productivity and portability.

In Low-Level Languages

In low-level languages such as and C++, runtime systems are typically lightweight libraries that provide essential support for program execution without the automated features found in higher-level environments. These systems emphasize explicit by the programmer, offering direct access to hardware and operating system services while minimizing overhead. The runtime library, exemplified by the GNU Library (), includes core functions for dynamic allocation via malloc and free, which allow developers to request and release heap manually. Additionally, handles program startup through initialization routines like those in crt0.o, which set up the execution environment before calling main, and shutdown via functions such as atexit for registering cleanup handlers. Signal handling is another key component, with functions like signal and sigaction enabling responses to asynchronous events such as interrupts or errors. For C++, the runtime extends these capabilities through libraries like libstdc++, which builds on the C runtime and adds support for language-specific features. Libstdc++ incorporates the low-level support library libsupc++, providing mechanisms for , (RTTI), and terminate handlers, all while relying on underlying C functions for memory and process management. In performance-critical applications, developers may implement custom runtime systems to tailor these components, such as bespoke allocators or stack unwinding logic, often using POSIX-standard setjmp and longjmp for non-local control transfers that simulate basic exception propagation without full overhead. In embedded systems, runtime systems are further minimized to suit resource-constrained environments like microcontrollers. Newlib, a compact library, serves as a prime example, offering implementations of standard functions including malloc/free and signal handling, but with configurable stubs for system calls to integrate with no-OS bare-metal setups or real-time operating systems (RTOS). This approach allows direct hardware interaction while avoiding the bloat of full-featured libraries like . The use of such explicit runtime systems in low-level languages grants developers fine-grained control over resources, enabling optimizations for speed and that are infeasible in managed environments. However, this control comes at the cost of increased error-proneness, as heightens risks of leaks, overflows, and without built-in safeguards. These trade-offs are particularly evident in , where runtime integration with the operating system—such as through syscalls for I/O—demands careful handling to maintain reliability.

Advanced Capabilities

Memory Management Techniques

Runtime systems employ various memory management techniques to allocate and deallocate memory efficiently during program execution, balancing performance, safety, and resource usage. One primary approach is garbage collection (GC), an automatic mechanism that identifies and reclaims memory occupied by unreachable objects, preventing memory leaks without explicit programmer intervention. Mark-and-sweep is a foundational tracing GC algorithm, first described in the context of implementations, where a marking phase traverses from root references to identify live objects, followed by a sweeping phase to free unmarked memory. This method ensures completeness by reclaiming all garbage but introduces stop-the-world pauses during collection, which can range from milliseconds to seconds depending on heap size, potentially impacting latency-sensitive applications. Pros include simplified programming and leak prevention; cons encompass non-deterministic pause times and overhead from tracing the object graph. Generational garbage collection builds on tracing algorithms by dividing the heap into generations based on object age, exploiting the weak generational hypothesis that most objects die young. Seminal work introduced generation scavenging, using a collector for the young generation (nursery) and mark-sweep for older ones, achieving significant throughput improvements, such as approximately three times faster than traditional methods in early implementations, by minimizing full collections. This reduces pause times for minor collections to under 1 ms in modern systems, though major collections can still cause longer interruptions; overall, it lowers by promoting only long-lived objects while enhancing allocation speed through bump-pointer techniques. Advanced variants include concurrent and low-latency garbage collectors, such as ZGC (introduced in JDK 11, with generational support in JDK 21 as of 2023) and Shenandoah, which perform most work concurrently with application threads to minimize pauses. These achieve sub-millisecond pause times (often under 1 ms even for large heaps up to terabytes) and high throughput, enabling scalable performance in server and cloud environments as of 2025. Reference counting is another automatic technique where each object maintains a count of incoming references, decrementing on release and deallocating when the count reaches zero. Originating in early graph structure management, it enables immediate reclamation without pauses, providing predictable latency and lower average due to on-demand freeing. However, it incurs runtime overhead from increment/decrement operations (typically 10-20% CPU in object-heavy workloads) and fails to collect cyclic references, necessitating hybrid approaches. In Python's runtime, serves as the primary mechanism, augmented by a cyclic GC using a mark-sweep variant for containers to handle loops. For manual allocation, runtime systems provide interfaces like malloc and realloc to request heap from the operating system or internal pools, allowing fine-grained control in performance-critical code. These functions manage fragmentation—where free becomes scattered into unusable small blocks—through strategies such as segregated free lists or buddy systems, which coalesce adjacent blocks to maintain larger contiguous regions and sustain allocation throughput above 90% efficiency in steady-state workloads. While offering minimal overhead and no pauses, manual management risks leaks or dangling pointers if mismanaged, with fragmentation potentially increasing effective usage by 20-50% over time without mitigation. Specialized techniques like region-based allocation address short-lived objects by grouping allocations into hierarchical s, deallocating entire regions at once upon scope exit, which avoids per-object overhead and fragmentation in temporary data structures. This approach, formalized in explicit region systems, excels for linear-time deallocation in O(1) operations per region, reducing latency for bursty allocations common in compilers or web servers, though it requires careful region scoping to prevent leaks. In terms of metrics, modern GC techniques like generational and concurrent collectors achieve allocation throughputs of hundreds to thousands of MB/s (e.g., 2-3 GB/s in JVM benchmarks) while keeping pauses under 100 ms for 4 GB heaps, but increase footprint by 10-30% due to metadata; maintains constant latency with 5-15% higher CPU usage; manual methods minimize footprint but demand developer effort to sustain low fragmentation and high throughput.

Execution Optimization Methods

Runtime systems optimize execution by dynamically transforming and adapting code to the underlying hardware and workload characteristics, thereby improving speed and efficiency without requiring upfront static analysis. These methods leverage runtime information, such as execution frequencies and data patterns, to apply targeted transformations that pure interpreters or ahead-of-time compilers cannot achieve. Key techniques include , hybrid interpretation-compilation strategies, profiling-guided optimizations like inlining, and support for vectorization and parallelism. Just-in-Time () compilation is a core optimization where the runtime system translates or intermediate representations into native during program execution, enabling platform-specific optimizations and adaptation to runtime behaviors. This process typically involves an initial interpretation phase for rapid startup, followed by compilation of frequently executed ("hot") code paths into optimized native code, often with multiple tiers of increasing optimization levels to balance compilation overhead and performance gains. Adaptive JIT further refines this by recompiling methods based on accumulated runtime profiles, such as branch probabilities or object types, to apply aggressive optimizations like or speculation. For instance, in managed runtimes like the JVM, the HotSpot JIT uses tiered compilation to achieve near-native performance while minimizing initial latency. Hybrid approaches combining interpretation and compilation address trade-offs between startup time and peak performance, where pure interpretation offers fast initial execution but limited optimization, while full compilation delays startup due to upfront costs. hybrids mitigate this by interpreting cold code quickly and compiling only hot regions on demand, resulting in startup times closer to interpreters (often under 100ms for small applications) while approaching speeds after warmup, with peak performance improvements of 2-10x over interpretation in benchmarks like SPECjvm. This balance is particularly valuable in interactive applications, where early responsiveness is critical, and the runtime dynamically decides compilation thresholds based on execution counts to optimize overall throughput. Profiling and inlining are runtime-driven techniques where the system collects execution data, such as method invocation counts and loop frequencies, to identify and optimize hot paths. Profiling instruments code minimally to gather metrics like call graphs or edge profiles without significant overhead (typically <5% slowdown), enabling decisions on transformations like method inlining, which replaces function calls with inline to eliminate call overhead and expose further optimizations. , another profiling-guided method, duplicates loop bodies to reduce iteration overhead and improve , often yielding 20-50% speedups on hot loops in empirical studies. These optimizations are applied incrementally in JIT compilers, with inlining heuristics considering factors like size limits to avoid bloating, ensuring compilation remains efficient even on resource-constrained systems. Vectorization and parallelism optimizations in runtime systems exploit hardware features like SIMD instructions and multi-core processors to accelerate data-parallel computations. For vectorization, the JIT compiler analyzes loops and applies auto-vectorization to generate SIMD code, such as using SSE/AVX instructions to process multiple data elements in parallel, achieving speedups of 2-8x on vectorizable workloads like numerical computations. Parallelism support involves runtime scheduling of multi-threaded execution, including thread creation, synchronization via locks or barriers, and load balancing across cores, with JIT optimizations like escape analysis to reduce locking overhead. In multi-threaded JIT scenarios, compilation policies adjust thread counts for parallel compilation phases, improving throughput by up to 30% on multi-core systems while maintaining single-threaded compatibility. These techniques are especially effective in data-intensive applications, where runtime adaptation to hardware vector widths enhances overall efficiency.

Historical Evolution

Origins in Early Computing

The origins of runtime systems emerged in the immediate post-World War II era, as electronic computers transitioned from manual configuration to more automated program execution support. The , completed in 1945, represented an early pinnacle of hardware computation but required physical reconfiguration via plugs and switches for each task, lacking dedicated software for loading or assembly. By contrast, the , introduced in 1952 as the company's first commercial scientific computer, incorporated rudimentary runtime mechanisms such as a punched-card loader that read the initial program word into memory via a dedicated "Load" button, enabling sequential execution without constant manual intervention. This loader provided basic runtime support by facilitating program initialization and memory setup on vacuum-tube based hardware. Complementing this, developed the first symbolic assembler for the around 1953, translating mnemonic instructions into to streamline programming and execution, thus forming an essential precursor to modern runtime translation layers. A pivotal advancement occurred with the advent of in the mid-1950s, marking the first explicit language-specific runtime system. Developed by and a team at , the compiler for the , released in 1957, generated efficient but relied on an accompanying to manage operations beyond core arithmetic, including formatted (I/O) via subroutines like READ and PRINT, and mathematical functions such as square roots and . This library, implemented as relocatable subroutines linked at load time, abstracted hardware-specific details, allowing programmers to focus on algorithms while the runtime handled execution-time support for data transfer and computation extensions. The system's design emphasized speed and reliability, with the runtime ensuring compatibility across IBM's 700-series mainframes and influencing subsequent high-level language implementations. Batch processing paradigms in 1950s mainframes further integrated runtime elements for resource management and job orchestration. On systems like the 704 and 709, runtime support evolved to handle batched job streams, where multiple programs were queued on or cards, and the system automatically sequenced their execution to optimize CPU utilization and minimize idle time between setups. This approach included primitive schedulers that allocated memory, initiated loaders for each job, and managed shared peripherals like tape drives, effectively providing runtime oversight for non-interactive workloads in scientific and applications. Such mechanisms reduced operator intervention and enabled efficient resource sharing among queued tasks, establishing foundational patterns for multiprogramming in early commercial computing environments. Key milestones in the built on these foundations with innovations in modular execution. The operating system, initiated in 1965 as a collaboration between MIT's Project MAC, Bell Telephone Laboratories, and , introduced dynamic linking as a core runtime feature on the GE-645 computer. Unlike static linking, which resolved procedure addresses at , ' dynamic resolved references at execution time using a segment-based model, allowing procedures to be loaded on demand and shared across processes without recompilation. This capability, detailed in early system overviews, enhanced flexibility in multi-user and served as a direct precursor to contemporary dynamic loaders in operating systems.

Developments in Modern Languages

Lisp's runtime, from its inception in 1958, pioneered automatic through garbage collection algorithms, such as mark-and-sweep, which became foundational for handling dynamic allocation without manual deallocation; these concepts profoundly shaped managed languages in the 1980s and . Smalltalk's runtime system, developed in the , introduced efficient via , allowing method resolution at execution time and influencing flexible polymorphism in later designs. This era culminated in Java's release by in 1995, which introduced the (JVM) as a secure, portable runtime environment supporting execution, automatic garbage collection, and platform independence. The 2000s saw further expansions with Microsoft's (CLR), released in 2002 as part of the .NET Framework, offering a managed execution environment with cross-language , , and integrated garbage collection for enterprise applications. Google's , launched in 2008, advanced runtimes by using to native code for high performance; it powered from 2009 onward, incorporating an event-driven, non-blocking concurrency model to handle I/O-intensive workloads efficiently on a single thread. From the 2010s to the 2020s, established a new paradigm for runtime systems, with its in 2017 and W3C standardization in 2019, providing a binary instruction format for safe, near-native execution in browsers and portable environments beyond the web. Rust's runtime, introduced in , adopted a minimalistic approach without garbage collection, relying on compile-time ownership and borrowing rules to enforce and prevent data races while enabling zero-cost abstractions. In the early 2020s, runtime systems increasingly integrated with frameworks, such as adaptive in ML runtimes like Apache TVM (enhanced through 2024 with ML-based autotuning for hardware optimization). Additionally, runtimes are evolving to better support , automating scaling and cold-start mitigation in function-as-a-service models to reduce operational overhead in distributed environments.

References

  1. https://www.techtarget.com/searchsoftwarequality/definition/runtime
  2. https://www.ics.forth.gr/carv/runtime-systems
  3. https://edge.seas.harvard.edu/runtime-systems
  4. https://dl.acm.org/doi/10.14529/jsfi170103
  5. https://docs.oracle.com/cd/E19620-01/805-4031/6j3qv1oec/index.html
  6. https://www.cse.wustl.edu/~angelee/cse539/papers/cilk1.pdf
  7. https://www.openmp.org/specifications/
  8. https://www.sciencedirect.com/topics/computer-science/runtime-system
  9. https://www.sciencedirect.com/science/article/pii/B9780123745149000264
  10. https://dl.acm.org/doi/10.1145/3102980.3103003
  11. https://www.baeldung.com/cs/runtime-vs-compile-time
  12. https://www.sciencedirect.com/science/article/pii/B9780123745149000367
  13. https://www.sciencedirect.com/book/9780128154120/engineering-a-compiler
  14. https://apps.dtic.mil/sti/tr/pdf/ADA311958.pdf
  15. https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqd/index.html
  16. https://www.sciencedirect.com/topics/computer-science/runtime-environment
  17. https://drops.dagstuhl.de/storage/01oasics/oasics-vol049_iccsw2015/OASIcs.ICCSW.2015.3/OASIcs.ICCSW.2015.3.pdf
  18. https://learn.microsoft.com/en-us/dotnet/standard/clr
  19. https://learn.microsoft.com/en-us/dotnet/standard/glossary
  20. https://science.osti.gov/-/media/ascr/pdf/research/cs/Exascale-Workshop/ExaOSR-Report-Final.pdf
  21. https://source.android.com/docs/core/architecture/hal
  22. https://dl.acm.org/doi/pdf/10.1145/326490.326529
  23. https://dl.acm.org/doi/pdf/10.5555/975000
  24. https://www.cs.rochester.edu/u/scott/papers/1991_SOSP_Psyche_first_class_threads.pdf
  25. https://learn.microsoft.com/en-us/dotnet/core/porting/net-framework-tech-unavailable
  26. https://sourceware.org/newlib/libc.html
  27. https://cacm.acm.org/research/safe-systems-programming-in-rust/
  28. https://cacm.acm.org/research/safe-to-the-last-instruction/
  29. https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/performissues003.html
  30. https://dl.acm.org/doi/10.1145/800020.808261
  31. https://www.oracle.com/technical-resources/articles/java/zgc.html
  32. https://openjdk.org/projects/shenandoah/
  33. https://devguide.python.org/internals/garbage-collector/
  34. https://theory.stanford.edu/~aiken/publications/papers/pldi98a.pdf
  35. https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/performance
  36. https://mill-build.org/blog/6-garbage-collector-perf.html
  37. https://www.cs.tufts.edu/comp/150IPL/papers/aycock03jit.pdf
  38. https://www.ittc.ku.edu/~kulkarni/CARS/papers/taco12.pdf
  39. https://www.ittc.ku.edu/~kulkarni/CARS/papers/pgo.pdf
  40. https://www.usenix.org/conference/java-vm-02/empirical-study-method-lining-java-just-time-compiler
  41. https://www.researchgate.net/publication/4193551_Continuous_path_and_edge_profiling
  42. https://www.cs.utexas.edu/~mckinley/papers/js-simd-pact-2015.pdf
  43. https://www.complang.tuwien.ac.at/andi/papers/scopes_16.pdf
  44. http://www.ittc.ku.edu/~kulkarni/CARS/papers/interact11.pdf
  45. https://hdl.loc.gov/loc.mss/eadmss.ms009241.3
  46. https://www.ibm.com/history/fortran
  47. https://www.ibm.com/history/ibm-704
  48. https://multicians.org/history.html
  49. http://landley.net/history/mirror/unix/multics/fjcc1.html
  50. https://groups.seas.harvard.edu/courses/cs252/2016fa/16.pdf
  51. https://dl.acm.org/doi/10.1145/3623507.3623551
  52. https://www.azul.com/products/core/a-brief-history-of-java/
  53. https://v8.dev/blog/10-years
  54. https://nodejs.org/en/about
  55. https://www.w3.org/TR/wasm-core-1/
  56. https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html
  57. https://tvm.apache.org/docs/
  58. https://dl.acm.org/doi/10.1145/3579643
Add your contribution
Related Hubs
User Avatar
No comments yet.