Hubbry Logo
Dynamic recompilationDynamic recompilationMain
Open search
Dynamic recompilation
Community hub
Dynamic recompilation
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Dynamic recompilation
Dynamic recompilation
Dynamic recompilation
View on Wikipedia
from Wikipedia

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

In computer science, dynamic recompilation is a feature of some emulators and virtual machines, where the system may recompile some part of a program during execution. By compiling during execution, the system can tailor the generated code to reflect the program's run-time environment, and potentially produce more efficient code by exploiting information that is not available to a traditional static compiler.

Uses

[edit]

Most dynamic recompilers are used to convert machine code between architectures at runtime. This is a task often needed in the emulation of legacy gaming platforms. In other cases, a system may employ dynamic recompilation as part of an adaptive optimization strategy to execute a portable program representation such as Java or .NET Common Language Runtime bytecodes. Full-speed debuggers also utilize dynamic recompilation to reduce the space overhead incurred in most deoptimization techniques, and other features such as dynamic thread migration.

Tasks

[edit]

The main tasks a dynamic recompiler has to perform are:

  • Reading in machine code from the source platform
  • Emitting machine code for the target platform

A dynamic recompiler may also perform some auxiliary tasks:

  • Managing a cache of recompiled code
  • Updating of elapsed cycle counts on platforms with cycle count registers
  • Management of interrupt checking
  • Providing an interface to virtualized support hardware, for example a GPU
  • Optimizing higher-level code structures to run efficiently on the target hardware (see below)

Applications

[edit]
  • Many Java virtual machines feature dynamic recompilation.
  • Apple's Rosetta for Mac OS X on x86, allows PowerPC code to be run on the x86 architecture.
  • Later versions of the Mac 68K emulator used in classic Mac OS to run 680x0 code on the PowerPC hardware.
  • Psyco, a specializing compiler for Python.
  • The HP Dynamo project, an example of a transparent binary dynamic optimizer.[1]
  • DynamoRIO, an open-source successor to Dynamo that works with the ARM, x86-64 and IA-64 (Itanium) instruction sets.[2][3]
  • The Vx32 virtual machine employs dynamic recompilation to create OS-independent x86 architecture sandboxes for safe application plugins.
  • Microsoft Virtual PC for Mac, used to run x86 code on PowerPC.
  • FreeKEYB, an international DOS keyboard and console driver with many usability enhancements utilized self-modifying code and dynamic dead code elimination to minimize its in-memory image based on its user configuration (selected features, languages, layouts) and actual runtime environment (OS variant and version, loaded drivers, underlying hardware), automatically resolving dependencies, dynamically relocating and recombining code sections on byte-level granularity and optimizing opstrings based on semantic information provided in the source code, relocation information generated by special tools during assembly and profile information obtained at load time.[4]
  • The backwards compatibility functionality of the Xbox 360 (i.e. running games written for the original Xbox) is widely assumed to use dynamic recompilation.
  • Apple's Rosetta 2 for Apple silicon, permits many applications compiled for x86-64-based processors to be translated for execution on Apple silicon.
  • QEMU

Emulators

[edit]
  • PCSX2,[5] a PlayStation 2 emulator, has a recompiler called "microVU", the successor of "SuperVU".
  • GCemu,[6] a GameCube emulator.
  • GEM,[7] a Game Boy emulator for MSX uses an optimizing dynamic recompiler.
  • DeSmuME,[8] a Nintendo DS emulator, has a dynarec option.
  • Soywiz's Psp,[9] a PlayStation Portable emulator, has a dynarec option.
  • Mupen64Plus, a multi-platform Nintendo 64 emulator.[10]
  • Yabause, a multi-platform Saturn emulator.[11]
  • PPSSPP, a multi-platform PlayStation Portable emulator, uses a JIT dynamic recompiler by default.[12]
  • PCem, an emulator for old pc platforms which can be used on Windows and Linux. It uses the recompiler to translate legacy cpu calls to modern cpu instructions and to gain some speed in emulation overall.
  • 86Box, a fork of PCem with the goal of a more accurate emulation. It is using the recompiler for the same purpose.

See also

[edit]

References

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

Dynamic recompilation

View on Grokipedia
from Grokipedia
Dynamic recompilation, also known as dynamic or dynarec, is a runtime technique in used primarily in emulators and virtual machines to translate from a guest processor architecture into executable native for the host processor. This on-the-fly translation enables software designed for one CPU to run efficiently on a different hardware platform by converting blocks of emulated instructions into optimized host , rather than simulating each instruction interpretively. The process typically involves just-in-time () compilation, where is analyzed, transformed, and cached for reuse, ensuring semantic equivalence to the original while leveraging the host's performance capabilities. In operation, dynamic recompilation begins by decoding guest instructions into an or directly into host instructions, often processing code in basic blocks between branch points to minimize overhead. A translation cache stores these recompiled blocks, allowing subsequent executions to bypass re-translation and run natively, with mechanisms like profiling to optimize hot code paths. To handle complexities such as , dynamic code generation, or exceptions, systems employ software checks, hardware protections (e.g., memory management unit faults), or protocols to maintain accuracy. This hybrid approach combines the flexibility of interpretation for initial setup with the speed of direct execution, making it suitable for emulating legacy systems like consoles or cross-platform compatibility layers. Historically, dynamic recompilation gained prominence in the amid growing interest in emulation and for architecture migration. Early implementations include Digital Equipment Corporation's FX!32 system (1997), which translated x86 binaries to Alpha processors for compatibility, and Apple's (initially interpretive, later incorporating dynamic translation) in the Power Macintosh starting in 1994 for migrating 680x0 code to PowerPC. Commercial applications extended into the 2000s, such as Transmeta's Crusoe processor using Code Morphing Software for x86 emulation on VLIW architectures, and HP's for runtime optimization. In modern contexts, it supports projects like those for retro gaming hardware and advanced recompilation frameworks such as BinRec, which lift binaries to intermediate representations like IR for security hardening, deobfuscation, and reoptimization; recent frameworks as of 2024 continue to advance dynamic lifting for such applications. The primary advantages of dynamic recompilation include substantial performance gains over pure interpretation—often by orders of magnitude—through reduced per-instruction overhead and native execution, while adapting to only the paths actually encountered. It excels in scenarios requiring high fidelity, such as emulating non-operating-system environments like game consoles, and facilitates innovations in binary analysis and transformation. However, challenges persist in managing coverage, handling obfuscated or dynamic , and balancing translation overhead with execution speed, particularly for large binaries.

Fundamentals

Definition and Principles

Dynamic recompilation, also known as dynamic binary translation, is a runtime technique that translates and recompiles executable code from a source instruction set architecture (ISA) into optimized machine code for the host architecture during program execution. This process enables software designed for one processor to run efficiently on another without prior static conversion, addressing compatibility across heterogeneous systems. The core principles of dynamic recompilation revolve around on-the-fly , where blocks of guest are dynamically decoded and mapped to equivalent host instructions as execution progresses. To mitigate repeated overhead, recompiled blocks are cached in , allowing direct execution of native upon subsequent encounters of the same guest instructions. Architectural differences, such as varying instruction sets, register counts, and , are handled through mapping mechanisms that allocate host resources to emulate guest behaviors accurately, often using temporary registers or for state preservation. At a high level, the begins with detecting and fetching a block of guest code from the program's execution stream, followed by disassembly into individual instructions. These are then analyzed for dependencies and , after which native code stubs are generated to replicate the semantics, incorporating any necessary emulation for host-guest mismatches. Unlike interpretation, which simulates each guest instruction step-by-step via a software loop, dynamic recompilation produces fully host code that runs directly on the processor, yielding superior for frequently executed paths while incurring initial translation costs. This technique finds prominent use in emulators, where it facilitates the of legacy hardware on modern platforms.

Comparison to Static Recompilation

Static recompilation, often referred to as static , involves translating an entire program's from a source to a target one prior to execution, typically offline or ahead-of-time. This approach enables thorough analysis, such as reconstructing and optimizing the full codebase, without incurring translation costs during runtime. Dynamic recompilation differs fundamentally by performing translation incrementally at runtime, recompiling blocks as they are encountered and executed. While static methods provide seamless runtime performance for predictable , they struggle with variability like conditional branches or data-dependent execution paths that only reveal themselves during program flow. Dynamic approaches address this by adapting translations on-the-fly but introduce overhead from repeated recompilation and cache management, potentially slowing initial execution phases. The trade-offs between these paradigms are evident in their suitability for different scenarios:
AspectStatic RecompilationDynamic Recompilation
Execution TimingPre-execution translation; no runtime pauses for translation.Runtime translation; spreads overhead but may cause minor execution interruptions.
FlexibilityBest for static, fully known binaries with minimal changes; limited handling of dynamic elements.Excels in environments with runtime variability, such as branches or loaded modules.
PerformanceFaster overall runtime due to optimized, fixed code; upfront compilation time can be lengthy for large programs.Initial overhead from translation, but enables runtime optimizations based on execution profiles.
Use CasesIdeal for or environments with low code variability.Preferred for interactive systems or code with unpredictable behaviors.
These comparisons highlight static recompilation's efficiency in controlled settings, contrasted with dynamic's robustness in variable contexts. Static recompilation proves inadequate for , where instructions are altered during execution, as the pre-translated code cannot reflect these changes without re-translation from scratch. Similarly, it falters with indirect jumps or dynamically loaded libraries that alter program structure post-compilation, leading to incomplete or erroneous translations. In such cases, dynamic recompilation is favored because it detects and reprocesses modified code blocks in real-time, ensuring correctness without halting the entire program. This adaptability makes dynamic methods more practical for complex, evolving execution environments.

Technical Mechanisms

Recompilation Process

Dynamic recompilation operates through a series of runtime phases that transform guest code into executable host-native instructions, enabling efficient emulation or optimization without prior static analysis. The process begins with code discovery, where the system identifies executable segments of guest code, typically by delineating basic blocks—sequences of instructions ending in a control transfer such as a jump or . This identification often starts at known entry points, like function beginnings, and proceeds on-demand via a central that monitors execution flow to detect uncached code regions. Following discovery, the guest code undergoes disassembly into an (IR), a platform-agnostic form that abstracts machine-specific details for easier manipulation. Disassembly decodes binary instructions using architecture-specific rules, converting them into a structured IR such as (RTL), which facilitates subsequent analysis and transformation. This step ensures portability across guest-host architectures by stripping away low-level idiosyncrasies, though it incurs overhead from repeated decoding of frequently executed code. The core transformation occurs in mapping, where IR instructions are translated to host equivalents, including register allocation that bridges architectural differences—such as mapping a guest's 32 general-purpose registers to a host's potentially different set via memory-based spilling or direct equivalence. Control flow is preserved by resolving jumps and branches: direct jumps are patched to point to translated targets, while indirect branches (e.g., computed jumps) are handled via auxiliary structures like switch tables or runtime resolution to maintain accurate execution paths. State maintenance, including exception handling and memory mapping, ensures the guest's architectural state remains consistent during translation. Finally, emission generates and stores the host-native in a translation cache for reuse, linking it into the execution flow via to bypass future interpretations of the same block. To prioritize efficiency, recompilation often targets execution traces—dynamic sequences of hot code paths identified through profiling counters that increment on block entries. When a counter exceeds a threshold, the trace is selected for recompilation, focusing resources on frequently executed loops or paths while cold code remains interpreted. This trace-based approach reduces overhead by creating larger, cohesive code units. For robustness, dynamic recompilers incorporate error handling mechanisms, such as fallbacks to interpretive execution for uncached, self-modifying, or exceptionally complex code that defies efficient . Write protections on guest code pages trigger traps (e.g., segmentation faults) to invalidate and retranslate affected cache entries, preventing inconsistencies from modifications during execution. These safeguards ensure correctness at the cost of occasional dips.

Optimization Strategies

Dynamic recompilation systems employ during (IR) analysis to identify and remove instructions that do not influence the program's observable state, thereby reducing the size of the generated host code and improving execution efficiency. This optimization is particularly valuable in , where unnecessary host instructions—such as those assigning values to unused registers—can be pruned after liveness analysis, minimizing both translation overhead and cache pressure. Complementing this, constant propagation substitutes variables with known constant values propagated through the IR, enabling further simplifications like and eliminating redundant computations. Together, these techniques during the IR stage compact the recompiled code, as demonstrated in systems like , where they contribute to overall performance gains by avoiding emission of superfluous operations. Register allocation in dynamic recompilation must account for architectural differences between guest and host architectures, often through explicit host-guest register mapping to assign guest registers to available host registers while preserving semantics. This mapping, typically stored in a per-block table, facilitates efficient by reusing host registers across basic blocks and reducing the need for loads and stores. When the host has fewer registers than the guest, spilling strategies become critical; these involve selectively evicting live values to (e.g., stack or dedicated spill areas) based on liveness intervals, with heuristics like linear scan allocation prioritizing high-frequency variables to minimize spill frequency and associated latency. Advanced spilling in dynamic contexts, such as layered allocation, incrementally assigns registers while deferring spills, balancing compilation speed and runtime in resource-constrained environments. These optimizations ensure that accesses, which can dominate execution time in mismatched architectures, are kept to a minimum. To accelerate hot code paths, dynamic recompilers apply , which replicates loop bodies to reduce iteration overhead and expose more , particularly beneficial for frequently executed loops identified via runtime profiling. Inlining complements this by substituting function calls with their bodies in the recompiled code, eliminating call-return overhead and enabling cross-function optimizations like further unrolling or on inlined traces. For branch-heavy paths, integrates with these by predicting branch outcomes based on dynamic profiles and generating code that assumes the likely path, with recovery mechanisms (e.g., checkpoints) for mispredictions to maintain correctness. This approach, as in trace-based systems like , chains frequently executed basic blocks into linear traces for unrolling and inlining, enhancing branch prediction accuracy and reducing disruptions. Effective management of the code cache is essential in dynamic recompilation to reuse translated fragments without excessive recompilation. Least-recently-used (LRU) eviction policies track access recency in code buffers, discarding infrequently executed fragments when space is limited to prioritize hot code retention. Multi-level caching structures further refine this: a first-level cache holds fine-grained basic blocks for quick insertion, while a second-level stores coarser traces or superblocks, allowing LRU-based promotion of frequently linked blocks into optimized, larger units that reduce linking overhead. In systems like , generational policies approximate LRU by partitioning the cache into generations, evicting older, less active traces first to balance eviction cost and reuse. These strategies ensure the code cache remains efficient, adapting to phases without flushing the entire buffer.

Historical Development

Origins and Early Examples

Dynamic recompilation emerged in the late as an evolution of emulation techniques, aimed at improving the of cross-architecture code execution during the transition from complex instruction set computing (CISC) to reduced instruction set computing (RISC) platforms. This approach involved runtime translation and optimization of , allowing legacy software to run efficiently on new hardware without full static recompilation. One of the earliest practical implementations occurred in the early with Digital Equipment Corporation's (DEC) binary translators for the Alpha RISC processor. DEC developed tools like mx, which dynamically translated Unix programs originally compiled for other architectures, and fx!32, a dynamic translator for running x86 Windows applications on Alpha systems, achieving near-native performance through on-the-fly code generation and caching. These systems demonstrated the viability of dynamic recompilation for broad software compatibility during architectural shifts. A prominent commercial example came in 1994 with Apple's transition to PowerPC processors. To support existing 68k-based Macintosh software, Apple integrated a dynamic recompiling directly into Mac OS (starting with System 7.1.2), which translated frequently executed 68k code blocks into optimized PowerPC-native instructions and cached them for reuse, enabling legacy applications to run at speeds approaching native execution. Key research contributions in the late further advanced the field. Hewlett-Packard's , detailed in a 1999 technical report and 2000 publication, introduced a transparent dynamic optimization framework that intercepted native execution streams, recompiled hot code fragments with aggressive optimizations, and improved overall program performance by up to 20% on HP PA-RISC systems without requiring modifications. Similarly, Transmeta's Crusoe processor, launched in 2000, utilized Code Morphing Software—a dynamic translation layer that converted x86 instructions to the processor's native (VLIW) format, incorporating speculation, recovery mechanisms, and adaptive retranslations to handle real-world workloads efficiently.

Evolution in Computing

In the and , dynamic recompilation advanced significantly in mobile and embedded systems, enabling cross-architecture compatibility without full static . A key example is 's Houdini library, introduced around 2012 as a dynamic layer for Android on x86 platforms, which translates instructions to x86 at runtime to run ARM-native applications on Intel Atom-based devices. This technology integrated with Android's runtime evolutions, including the shift from Dalvik's to the (ART)'s in Android 5.0 (2014), ensuring seamless execution of native code across and x86 ecosystems in resource-constrained environments. By 2020, similar translation mechanisms were refined in the Android Emulator for system images, allowing ARM apps to run on x86 hosts via on-demand instruction translation without broader system overhead, thus supporting development and testing on diverse hardware. In modern contexts, dynamic recompilation has been pivotal in Apple's Rosetta 2, introduced in 2020 for on , which dynamically translates binaries to ARM64 instructions at runtime, enabling Intel-based macOS applications to run efficiently on M-series processors with caching for repeated executions. Additionally, GPU-assisted dynamic recompilation has gained traction, as seen in NVIDIA's NVBit framework (2019), which employs runtime recompilation of SASS (Shader Assembly) code to instrument and optimize GPU kernels, enabling efficient analysis and acceleration in parallel environments without source code access. As of November 2025, dynamic recompilation continues to evolve in projects and cross-platform tools, supporting high-performance emulation of legacy architectures and integration with advanced runtime environments.

Applications

Emulators and

Dynamic recompilation plays a central role in CPU by enabling the real-time translation of guest instructions from a target architecture to executable host code, improving performance over interpretive methods. In , the Tiny Code Generator (TCG) implements this through dynamic , where blocks of guest instructions are analyzed and converted into optimized host instructions during runtime, allowing efficient emulation of diverse architectures such as , PowerPC, and MIPS on x86 hosts. In environments, dynamic recompilation facilitates full virtualization by addressing architectural incompatibilities without requiring guest OS modifications. historically employed adaptive to monitor and recompile sensitive x86 instructions that could trap the hypervisor, thereby maintaining isolation while minimizing overhead in paravirtualized scenarios. Similarly, KVM, when integrated with , leverages TCG for emulating non-hardware-accelerated components, reducing virtualization overhead in paravirtualized I/O paths like virtio devices by translating guest code to host-native execution. A prominent case study is the Dolphin emulator for GameCube and Wii consoles, which uses dynamic recompilation to translate PowerPC instructions to x86 assembly, achieving high-fidelity performance that supports full-speed emulation at resolutions up to 1080p with enhancements like widescreen hacks. This approach allows Dolphin to execute translated code blocks directly on the host CPU, bypassing slower interpretation and enabling features such as multiplayer networking over emulated hardware. Full-system emulation using dynamic recompilation faces significant challenges in handling peripherals and I/O operations, as these often lack native host support and require custom modeling to mimic device behaviors accurately. Emulators like QEMU must simulate hardware interfaces such as timers, network cards, and storage controllers, but limited peripheral models in base implementations can lead to incomplete functionality or performance bottlenecks without extensive customization.

Just-In-Time Compilation

Just-in-time (JIT) compilation represents a key application of dynamic recompilation in virtual machines for high-level programming languages, where intermediate code such as is translated to native at runtime to optimize execution based on observed program behavior. This approach enables adaptive performance improvements by recompiling "hot" code paths—frequently executed sections—while initially interpreting less critical portions to minimize startup overhead. Unlike static compilation, JIT leverages runtime profiling to apply language-specific optimizations, such as type specialization and inlining, which are infeasible ahead-of-time due to dynamic language features like polymorphism. In the Java HotSpot virtual machine, dynamic recompilation integrates seamlessly into the process, where the interpreter first executes and collects profiling data to identify hot methods—those invoked frequently or with high loop counts. The Client Compiler (C1) provides quick, lightly optimized compilation for rapid warmup, while the Server Compiler (C2) performs aggressive recompilation of these hot methods into highly optimized native code, incorporating techniques like method inlining and . This tiered system ensures that compilation overhead is amortized over long-running applications, with HotSpot's adaptive optimization continuously monitoring execution to trigger recompilation as program behavior evolves. The V8 JavaScript engine employs a multi-tier pipeline for dynamic recompilation, starting with Ignition, a bytecode interpreter that generates and executes unoptimized bytecode from parsed JavaScript, serving as a fallback for cold code and enabling fast initial execution with low memory overhead. For hot code paths, Ignition feeds profiling data to TurboFan, V8's optimizing compiler, which recompiles the bytecode into machine code using a "Sea of Nodes" intermediate representation to enable advanced optimizations like loop unrolling and dead code elimination. This setup allows V8 to adapt to JavaScript's dynamic typing by recompiling based on runtime observations, balancing compilation speed and peak performance in environments like web browsers. WebAssembly runtimes, such as Wasmtime, utilize dynamic recompilation through Cranelift, a code generator that translates modules from their structured to native code at runtime, emphasizing fast compilation for secure, embeddable execution. Cranelift's design prioritizes verification and hardening against malformed inputs, producing code that achieves near-native performance while supporting platforms including and . In Wasmtime, this enables just-in-time translation of functions invoked dynamically, with Cranelift's single-pass IR lowering ensuring low-latency startup for modular, applications. Adaptive optimization in these JIT systems relies on deoptimization mechanisms to handle runtime changes, such as type specializations becoming invalid due to dynamic features or profile invalidation from altered execution paths. In HotSpot, deoptimization traps optimized code frames back to interpreter state when assumptions like monomorphic call sites fail, allowing safe recovery without halting the VM and enabling subsequent recompilation with updated profiles. Similarly, V8's uses deoptimization to revert to Ignition's when type feedback proves inaccurate, preserving speculation's benefits while mitigating risks in dynamic environments. This technique, rooted in speculative optimizations, ensures robustness across implementations by balancing aggressive compilation with verifiable recovery paths.

Advantages and Challenges

Performance Benefits

Dynamic recompilation, also known as , delivers significant performance gains by converting guest instructions into optimized native host code at runtime, enabling execution at speeds far exceeding pure interpretation methods. After an initial warm-up phase where code fragments are translated and cached, systems achieve speedups of 2-10x or more over interpretation, as the recompiled code eliminates the per-instruction overhead of emulation while allowing aggressive optimizations tailored to the host . For instance, trace-based just-in-time compilers in resource-constrained environments report 7-11x speedups on regular workloads and around 3x on irregular code patterns compared to interpreters. In emulator applications like , this translates to near-native execution velocities post-caching, substantially reducing slowdowns. Memory efficiency is enhanced through shared code caches that minimize redundancy across execution traces and threads, particularly in multi-threaded scenarios. By maintaining a unified cache of translated blocks accessible to multiple cores or processes, dynamic recompilation avoids duplicating similar code fragments, leading to lower and fewer cache misses in concurrent environments. This approach, as implemented in frameworks like DynamoRIO, supports scalable performance in parallel workloads by reusing optimized translations, reducing overall memory pressure compared to per-thread private caches. The technique's adaptability stems from runtime profiling, which gathers execution data to guide selective recompilation of hotspots, yielding significant performance improvements on irregular or workload-varying code by applying context-specific optimizations unavailable at static compile time. In dynamic compilation systems, this profiling enables fine-grained adjustments, such as voltage and , resulting in energy savings of up to 70% for floating-point benchmarks and 44% for workloads in mobile devices handling variable loads, with minimal performance degradation (0.5-5%). These benefits make dynamic recompilation particularly effective for battery-constrained platforms where instruction cycles must be minimized without sacrificing responsiveness.

Implementation Limitations

One significant limitation of dynamic recompilation is the initial startup latency introduced by the compilation process, where blocks must be translated and optimized before execution begins, delaying the realization of performance gains. In systems like , this manifests as a fixed overhead for initializing data structures and fragment caches, which can constitute a non-negligible portion of the total runtime for short-lived applications such as image processing benchmarks. Typical overall startup latency ranges from tens of milliseconds to a few seconds for application warm-up, depending on the complexity of the and the optimization level applied. This latency arises because dynamic recompilers must analyze and generate native on-the-fly, contrasting with the immediate execution of precompiled binaries. Another challenge is code size bloat, where the generated often exceeds the size of the original by factors of 2 to 5 times, primarily due to the insertion of mappings, exception guards, and alignment padding to ensure safe execution. For instance, in debugging-enhanced JIT compilers, dynamic recompilation can lead to substantial growth in code size unless carefully managed, as each recompiled method incorporates additional instrumentation and profiling hooks. This expansion not only increases but also potentially degrades instruction cache locality and (TLB) efficiency, exacerbating overhead in resource-constrained environments. In dynamic optimization frameworks, the fragment cache used to store recompiled traces further contributes to this bloat, as traces are built incrementally and may include redundant guards for . Security risks pose a critical hurdle, as runtime code generation creates writable and executable memory regions that violate the W⊕X (write XOR execute) policy, making systems vulnerable to exploits such as (ROP) chains if not properly isolated. Attackers can leverage race conditions in multi-threaded JIT environments to inject into code caches, bypassing defenses like (ASLR) and (CFI); for example, vulnerabilities in browser JIT engines like V8 have enabled such attacks with high success rates through heap overflows or use-after-free bugs. Without sandboxing or multi-process isolation, dynamic recompilers risk facilitating , as demonstrated in exploits against Chrome's Web Workers where compilation states are manipulated to overwrite generated code. Portability issues further complicate deployment, as host-specific optimizations in the recompiled code—such as architecture-tailored instruction selection and scheduling—hinder reuse across different platforms, requiring retargeting efforts for each new host . In systems like , performance metrics are highly dependent on the target processor, such as the PA-8000, with branch prediction and TLB behaviors varying significantly between architectures, limiting cross-platform applicability. This host dependency arises because dynamic recompilers generate machine-specific binaries, often necessitating architecture-specific backends and reducing the ease of migration in environments. These limitations trade off against potential speedups but underscore the need for careful system design in multi-architecture scenarios.

References

  1. http://www.xsim.com/papers/Bario.2001.emubook.pdf
  2. https://www.cs.cmu.edu/afs/gco/archive/twiki/pub/Main/PoornimaKamath/bintrans.pdf
  3. https://dl.acm.org/doi/10.1145/3342195.3387550
  4. https://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf
  5. https://dl.acm.org/doi/10.1145/3689490.3690406
  6. https://www.complang.tuwien.ac.at/schani/papers/bintrans.pdf
  7. https://www.usenix.org/legacy/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf
  8. https://nebelwelt.net/files/09AMAS-BT.pdf
  9. https://www.researchgate.net/profile/Cristina-Cifuentes/publication/3673950_Binary_translation_static_dynamic_retargetable/links/53d8cbbe0cf2631430c35579/Binary-translation-static-dynamic-retargetable.pdf
  10. https://www.mdpi.com/2079-9292/12/14/3025
  11. https://stackoverflow.com/questions/16724593/why-is-dynamic-binary-translation-more-practical-than-static-binary-translation
  12. https://courses.cs.vt.edu/~cs5204/fall07-kafura/Papers/Virtualization/Binary-Translation.pdf
  13. https://www.cse.iitm.ac.in/~krishna/courses/2022/odd-cs6013/BalaDusterwaldBanerjiaPLDI2000.pdf
  14. https://lettieri.iet.unipi.it/virtualization/2014/vh05.pdf
  15. https://www.complang.tuwien.ac.at/andi/papers/wcre_02.pdf
  16. http://www.ittc.ku.edu/~kulkarni/teaching/EECS768/slides/chapter4.pdf
  17. https://cseweb.ucsd.edu/classes/sp00/cse231/dynamopldi.pdf
  18. https://lettieri.iet.unipi.it/virtualization/2015/vn03.pdf
  19. https://silviocesare.wordpress.com/2009/03/19/trying-to-figure-out-register-allocation-in-dynamic-binary-translation/
  20. https://inria.hal.science/hal-00911887/PDF/57_Diouf.pdf
  21. https://hal.science/hal-01856163v1/document
  22. https://www.researchgate.net/publication/3226288_Speculative_Loop-Pipelining_in_Binary_Translation_for_Hardware_Acceleration
  23. https://www.researchgate.net/publication/220117943_Code_cache_management_based_on_working_set_in_dynamic_binary_translator
  24. http://cgo.org/cgo2004/papers/07_6_hazelwood_k.pdf
  25. https://www.microarch.org/micro33/tutorial/m33-t-dcd.pdf
  26. https://theory.stanford.edu/~aiken/publications/papers/osdi08.pdf
  27. https://www.sciencedirect.com/topics/computer-science/binary-translator
  28. https://thechipletter.substack.com/p/apple-transitions-68k-to-powerpc
  29. https://dl.acm.org/doi/10.1145/358438.349303
  30. https://source.android.com/docs/core/runtime
  31. https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html
  32. https://dl.acm.org/doi/10.1145/3352460.3358307
  33. https://www.qemu.org/docs/master/devel/tcg.html
  34. https://www.cse.iitb.ac.in/~mythili/virtcc/papers/vmware.pdf
  35. https://www.dolphin-emu.org/
  36. https://www.osti.gov/servlets/purl/1760456
  37. https://dl.acm.org/doi/fullHtml/10.1145/3423167
  38. https://openjdk.org/groups/hotspot/docs/RuntimeOverview.html
  39. https://v8.dev/docs/turbofan
  40. https://dl.acm.org/doi/10.1145/2576195.2576209
  41. https://cr.openjdk.org/~vlivanov/talks/2015_JIT_Overview.pdf
  42. https://v8.dev/docs/ignition
  43. https://v8.dev/blog/launching-ignition-and-turbofan
  44. https://cranelift.dev/
  45. https://arxiv.org/abs/2011.13127
  46. https://bytecodealliance.org/articles/wasmtime-and-cranelift-in-2023
  47. https://labs.oracle.com/pls/apex/f?p=LABS:0:3655487670028:APPLICATION_PROCESS=GETDOC_INLINE:::DOC_ID:993
  48. https://www.usenix.org/legacy/event/vee06/full_papers/p144-gal.pdf
  49. https://www.usenix.org/system/files/atc19-song_0.pdf
  50. https://sigops.org/s/conferences/sosp/2013/papers/p101-kedia.pdf
  51. https://dl.acm.org/doi/10.1109/CGO.2006.36
  52. https://www.cs.rochester.edu/~cding/Documents/Publications/pldi99.pdf
  53. https://dl.acm.org/doi/pdf/10.1109/MICRO.2005.7
Add your contribution
Related Hubs
User Avatar
No comments yet.