Pith. sign in

REVIEW 3 major objections 4 minor 47 references

Deegen: A JIT-Capable VM Generator for Dynamic Languages

T0 review · 3 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Deegen claims that a two-tier VM with a state-of-the-art interpreter and baseline JIT can be generated automatically from C++ bytecode semantics, and backs the claim with a Lua 5.1 implementation that beats the PUC Lua interpreter by 179%.

desk verdict First static generation of a competitive interpreter and baseline JIT from bytecode semantics, with strong empirical evidence; the omitted correctness argument for type-check elimination is the main gap, and it is testable. read the letter →

arxiv 2411.11469 v2 pith:BTFN27FE submitted 2024-11-18 cs.PL

Haoran Xu , Fredrik Kjolstad This is my paper · ORCID
classification cs.PL
keywords DeegendynamiclanguageVMsbytecodesemanticsmeta-compilerinlinecachingbaselineJITtype-basedoptimizationCopy-and-Patch
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Deegen is a meta-compiler: instead of writing a VM by hand, the language implementer writes each bytecode's execution semantics as a C++ function, and Deegen generates, at build time, a complete two-tier execution engine---an optimized interpreter, a baseline JIT, and the profiling, tier-up, and on-stack-replacement logic that switches between them. The paper's central claim is that this automatic path reaches performance previously reserved for hand-assembled VMs: the generated Lua VM's interpreter is 179% faster than PUC Lua and 31% faster than LuaJIT's interpreter, and its baseline JIT, with negligible startup cost, is 360% faster than PUC Lua and only 33% slower on average than LuaJIT's optimizing JIT. Because everything is generated from a single source of truth, the engineering cost stays close to that of writing a simple interpreter: 42 bytecode definitions expand into 255 specialized bytecodes, versus roughly 86 hand-written bytecode handlers in the comparison LuaJIT. The paper explicitly frames a third-tier optimizing JIT as future work, so this is a demonstration of the two lower tiers rather than of a full multi-tier optimizing pipeline.

What carries the argument

The load-bearing mechanism is the bytecode semantic description framework. Users specify operands, result types, variants, speculative type hints, and slow paths through Deegen APIs, while the execution semantics themselves are ordinary C++ functions compiled to LLVM IR. Algorithm A, the core of the type-based optimization, runs sparse conditional constant propagation once per combination of guessed operand types, recording which type checks are trivially true, trivially false, or reducible by user-supplied strength-reduction rules; this turns type speculation into automatic fast-path and slow-path splitting. Generic inline caching is expressed as an idempotent computation $\lambda_i$ mapping an IC key to an IC state, followed by a cheap effect $\lambda_e(\text{Input}, \text{state})$; Deegen desugars these lambdas into tier-specific code, monomorphic with quickening in the interpreter and polymorphic self-modifying stubs in the JIT. Baseline JIT code generation is Copy-and-Patch: bytecode contents and IC state are burnt in as constants, and a CallBr (asm-goto) IR trick lets Deegen extract main-logic and IC-stub stencils from ordinary LLVM-generated assembly, including the inline-slab self-modifying stub chain.

What would settle it

Take LJR's Add bytecode, which splits on a speculation that both operands are tDoubleNotNaN, and execute it with one operand a NaN boxed as an impure NaN or a table; if the generated fast path produces a result different from PUC Lua's rather than transferring to the slow path, Algorithm A or the user-supplied type description is unsound. A systematic version is to mutate one strength-reduction rule in the type-hierarchy description and rerun the 44-benchmark suite against PUC Lua, since any divergence in outputs would falsify the automatic-optimization claim independently of the speed numbers.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that the two hardest components of a dynamic-language VM---a state-of-the-art interpreter and a baseline JIT---can be produced automatically rather than written by assembly experts, and that this generation can happen without surrendering either startup speed or steady-state throughput. Deegen compiles the C++ bytecode semantics to LLVM IR, runs domain-specific passes for type-check removal, strength reduction, inline-cache lowering, hot-cold splitting, and stencil extraction, and emits a self-contained runtime that uses Copy-and-Patch to generate machine code on demand. The resulting VM, LuaJIT Remake, is a standard-compliant Lua 5.1 implementation whose interpreter outperforms PUC Lua by 179% and LuaJIT's interpreter by 31%, and whose baseline JIT compiles 19.1 million bytecodes per second while running 360% faster than PUC Lua and 33% slower than LuaJIT's optimizing JIT, and faster on 13 of 44 benchmarks.

Load-bearing premise

The load-bearing premise is that the automatically produced type-specialized fast paths are semantically correct whenever the user's type hierarchy and strength-reduction rules are correct, but the paper omits the correctness proof with "We omit an argument of correctness due to space," so a silent miscompile in Algorithm A would invalidate the generated VM while leaving all speed measurements intact.

Editorial extensions

If this is right

  • A language implementer can obtain both an interpreter and a baseline JIT by writing only bytecode semantics; the tier-up and OSR-entry glue is emitted automatically.
  • Variant-based specialization means engineering cost scales with semantic definitions rather than with the number of optimized bytecode forms: 42 definitions produce 255 specialized variants.
  • Because the baseline JIT compiles at gigabytes per second, the interpreter-to-JIT transition can be hotness-driven without observable startup pauses on short-running workloads.
  • If the described third-tier optimizing JIT is built, the design predicts that the remaining peak-throughput gap to optimizing JITs will be closable without changing the user-facing bytecode description.
  • Since both tiers come from one source of truth, language-semantics changes propagate consistently to the interpreter and the JIT instead of requiring synchronized hand edits.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond what the paper claims, the architecture suggests that the build-time/runtime split is the real enabler: expensive analyses such as SCCP over type combinations and assembly CFG inspection run once per bytecode definition, not once per user program, which is what makes automatic JIT generation practical.
  • The same Copy-and-Patch and CallBr machinery could plausibly be reused outside VMs---for DSL runtimes, tree-walking evaluators, or event-driven frameworks---where one semantic description should yield both a fast interpreter and a quick JIT.
  • A testable extension is to vary the user-supplied type hierarchy and strength-reduction rules, for example adding a small-integer fast path or a tagged-pointer type, and check whether the generated interpreter and JIT track hand-written design expectations; the paper's claim predicts Deegen will exploit any rule expressible in its API.
  • An implicit production risk the paper does not resolve is that mis-specified IC annotations, such as wrong impossible-key values or wrong range annotations, are documented as undefined behavior, so a production version would need a debug mode that validates these annotations at runtime.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper presents Deegen, a build-time meta-compiler that takes C++ descriptions of bytecode execution semantics and automatically generates a two-tier VM consisting of a register-pinned, continuation-passing interpreter and a Copy-and-Patch based baseline JIT, together with profiling, tier-up, and OSR-entry logic. The user writes bytecode semantics as C++ functions using Deegen APIs, and Deegen performs LLVM-IR-level transformations for type-based optimization, inline caching, tag-register optimization, and other dynamic-language optimizations. The paper validates the approach with LuaJIT Remake (LJR), a Lua 5.1 VM, reporting interpreter performance 179% faster than PUC Lua and 31% faster than LuaJIT's interpreter, and baseline JIT performance 360% faster than PUC Lua and 33% slower than LuaJIT's optimizing JIT, with JIT compilation throughput of 1.62 GiB/s.

Significance. If the claims are correct, Deegen is a substantial advance in VM construction: it offers a single source of truth for bytecode semantics and automatically produces an interpreter and a baseline JIT whose generated assembly is competitive with hand-written VM code. The paper provides concrete evidence in the form of real disassembly listings, 44 benchmarks, an open-source artifact, and direct performance measurements rather than fitted models. The main substantive gap is the absence of a correctness argument for the type-based optimization algorithm in Section 5.1, which is load-bearing for the central claim that Deegen automatically generates a correct VM.

major comments (3)
  1. [§5.1, Algorithm A] The paper states 'We omit an argument of correctness due to space' immediately after describing Algorithm A, which replaces type-checker calls with true/false constants under SCCP and then splits code into fast and slow paths. This is a load-bearing omission: the generated VM's correctness depends on (i) each user-supplied type checker being a pure predicate over the operand's type with no side effects or hidden state, and (ii) the user-declared type hierarchy faithfully modeling the actual boxing scheme. Neither requirement is stated as an API contract or verified by the framework. A type checker that, for example, consults a hidden-class cache or an environment flag would change behavior when replaced by a constant, and a wrong type lattice could silently produce incorrect code on the fast path. The paper should either provide a formal soundness statement for Algorithm A under explicit assumptions about the type-checker API, or supply a differential fuzz test that compares executions of the optimized and unoptimized VM on a broad set of programs; without one of these, the 'automatically generated correct VM' claim is not supported.
  2. [§8, Evaluation] The evaluation measures performance but never verifies that LJR produces the same observable results as PUC Lua or LuaJIT on the 44 benchmarks. Since the paper claims LJR is 'standard-compliant' and uses that compliance to argue for Deegen's correctness, the absence of any output comparison or conformance testing is a gap. Even if Algorithm A were proven correct, the implementation could still have lowering bugs in the interpreter, JIT, or inline-cache machinery. Adding a differential test harness that runs the same benchmarks under LJR and PUC Lua and compares outputs would directly address this concern and is feasible within the manuscript's scope.
  3. [§5.1, type-checker API contract] Even setting aside the proof, the paper should specify the exact obligations of the user when defining type checkers and strength-reduction rules. The current text describes syntactic tuples ⟨S,c,d,e⟩ but does not state that c must be a pure function of the boxed value's type, nor that d/e must be inverses on the corresponding domain, nor that the type hierarchy must be a partition refinement of the concrete value representation. Without these contracts, the 'user-provided cost estimation' and rule selection in Algorithm A are not enough to guarantee that a chosen strength reduction preserves semantics. This is fixable by adding a short 'soundness requirements' subsection or a formal lemma.
minor comments (4)
  1. [§8.3] Performance numbers are reported as averages of three runs on a single machine with no error bars, variation, or per-run data; given the small run count, adding at least min/max or standard deviation would make the headline comparisons more robust.
  2. [§5.1, Algorithm A complexity] Algorithm A runs SCCP |T|^n times, where n is the number of bytecode operands; the paper notes this is acceptable at build time, but it would be useful to report the actual build-time cost for the 42 bytecode definitions in LJR, since this affects the 'engineering cost similar to a simple interpreter' claim.
  3. [§8.1, Figure 25] The lines-of-code comparison would be clearer if it stated whether the LJR LLOC count includes the user-written parser and standard-library stubs, since those are part of the total engineering effort of building a VM with Deegen.
  4. [§7.1, Figure 18] The disassembly figure for GetById is dense and the labels are small; a high-resolution version or an annotated walkthrough would help readers verify the claims about self-modifying code and inline slabs.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Deegen's claims rest on direct external measurements and a substantial, independently published Copy-and-Patch foundation.

full rationale

Deegen's central derivation—from C++ bytecode semantics to a generated interpreter and baseline JIT—is not circular. The headline performance claims are direct measurements of LJR against external baselines (PUC Lua and LuaJIT) on standard benchmark suites, with no fitted parameter or predicted quantity that reduces to an input. The type-based optimization pass in Section 5.1 does omit a correctness argument ('We omit an argument of correctness due to space'), but that is a soundness gap, not a circular step: the optimized function is not defined in terms of the claim it supports, and no result is renamed from its inputs. The self-citation of Copy-and-Patch [Xu and Kjolstad 2021] is a normal technique citation; Copy-and-Patch is independently published, and the present paper contributes a substantial extension (CallBr-based IC, stencil extraction, polymorphic IC, hot-cold splitting). No uniqueness theorem, ansatz, or fitted input is imported from the authors' prior work, and no 'prediction' in the paper is obtained by fitting or by definitional equivalence to its inputs.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the correctness of Deegen's automatic transformations even though no formal correctness proofs are provided. The paper trusts user-supplied descriptions of the language's type system and boxing scheme, and relies on a small LLVM backend modification to support IC extraction. These are stated as assumptions. The engineering limits (max 10^6 locals, 256MB SlowPathData) are hand-chosen but do not affect the claims materially.

free parameters (2)
  • Maximum number of locals in a function = 10^6
    Arbitrary engineering limit set during runtime constant range analysis; if exceeded, code generation fails. Not fitted to data and does not affect reported results.
  • Maximum SlowPathData stream length = 256 MB
    Arbitrary limit for SlowPathData offset range analysis; if exceeded, generation fails. Not fitted to data and does not affect reported results.
assumptions (4)
  • domain assumption Type-based optimization algorithm A is semantics-preserving under the stated type preconditions
    Section 5.1: 'We omit an argument of correctness due to space.' The transformation relies on the user-defined type hierarchy and strength-reduction rules being correct; no formal proof is given.
  • domain assumption User-provided boxing scheme and type hierarchy (checkers, encoders, decoders, strength reduction rules) are correct
    Section 4, 5.1: Deegen trusts the user description; a bug in TValue::Is/As/Create or type mask definitions would silently miscompile guest programs.
  • domain assumption The modified LLVM backend correctly dumps indirect branch targets as assembly comments, which are used to reconstruct the CFG for IC extraction
    Section 7.2: 'we modified a few lines of the LLVM backend to let it dump indirect branch targets as comments'; the correctness of IC extraction depends on this.
  • standard math x86-64 small code model ABI range [1, 2^31 - 2^24) for external symbol addresses is honored by all runtime constant expressions patched into stencils
    Section 7.2: The paper assumes this ABI fact and statically proves that runtime constant expressions fit; if the proof misses a case, patched machine code would be incorrect.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Deegen: A JIT-Capable VM Generator for Dynamic Languages." pith.science (2026). https://pith.science/paper/BTFN27FE

@misc{pith2026241111469,
  author       = {Pith},
  title        = {Pith review of: Deegen: A JIT-Capable VM Generator for Dynamic Languages},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BTFN27FE}},
  note         = {Machine review of arXiv:2411.11469}
}
read the original abstract

Building a high-performance JIT-capable VM for a dynamic language has traditionally required a tremendous amount of time, money, and expertise. We present Deegen, a meta-compiler that allows users to generate a high-performance JIT-capable VM for their own language at an engineering cost similar to writing a simple interpreter. Deegen takes in the execution semantics of the bytecodes implemented as C++ functions, and automatically generates a two-tier VM execution engine with a state-of-the-art interpreter, a state-of-the-art baseline JIT, and the tier-switching logic that connects them into a self-adaptive system. We are the first to demonstrate the automatic generation of a JIT compiler, and the automatic generation of an interpreter that outperforms the state of the art. Our performance comes from a long list of optimizations supported by Deegen, including bytecode specialization and quickening, register pinning, tag register optimization, call inline caching, generic inline caching, JIT polymorphic IC, JIT IC inline slab, type-check removal and strength reduction, type-based slow-path extraction and outlining, JIT hot-cold code splitting, and JIT OSR-entry. These optimizations are either employed automatically, or guided by the language implementer through intuitive APIs. As a result, the disassembly of the Deegen-generated interpreter, baseline JIT, and the generated JIT code rivals the assembly code hand-written by experts in state-of-the-art VMs. We implement LuaJIT Remake (LJR), a standard-compliant Lua 5.1 VM, using Deegen. Across 44 benchmarks, LJR's interpreter is on average 179% faster than the official PUC Lua interpreter, and 31% faster than LuaJIT's interpreter. LJR's baseline JIT has negligible startup delay, and its execution performance is on average 360% faster than PUC Lua and only 33% slower (but faster on 13/44 benchmarks) than LuaJIT's optimizing JIT.

Figures

Figures reproduced from arXiv: 2411.11469 by the authors.

Figure 1
Figure 1. Overview of the Deegen framework that generates a JIT-capable VM automatically. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. C++ semantics for a hypothetical add bytecode. For a quick sense of the Deegen framework, [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Bytecode specification for the hypo￾thetical add bytecode (C++ code). The execution semantic is not everything that de￾fines a bytecode: we also need to know, for example, where the operands come from, and whether the byte￾code produces an output value and/or can branch to another bytecode. This is achieved by the Deegen byte￾code specification shown in [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (17 more)
Figure 4
Figure 4. Figure 4: Emit an add bytecode using the bytecode builder API. Deegen is unaware of the guest language syntax. The user is re￾sponsible for implementing the parser that builds up the bytecode stream from the program source. For this purpose, Deegen generates a rich set of byteco…
Figure 5
Figure 5. Figure 5: The runtime baseline JIT compilation pipeline. Baseline JIT. The primary goal of the baseline JIT is to compile as quickly as possible. Generating good code is certainly desirable, but a secondary priority. To this end, the baseline JIT generated by Deegen lowers a byt…
Figure 6
Figure 6. Figure 6: A simplified illustration of how polymorphic IC works in the JIT. Inline Caching. Inline caching (IC) is a critical optimization for all VM tiers. Deegen has two IC mechanisms: call IC and generic IC. The call IC optimizes guest language function calls: Deegen automati…
Figure 7
Figure 7. Figure 7: Inter-bytecode control flow. Inter-Bytecode Control Flow. The control flow transfer between bytecodes needs to be implemented differently in each VM tier, and the ability to understand the CFG is important for the future optimizing JIT. Thus, users must use Deegen APIs…
Figure 8
Figure 8. Figure 8: Bytecode components and the control flow between them. Intra-Bytecode Control Flow. The execution semantics of a bytecode consists of multiple components [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: A computation is eligible for IC iff it meets the above characterization. Generic Inline Caching. Inline caching can greatly speed up object accesses, a pervasive operation in dynamic languages. However, it is hard to provide a universal object representa￾tion that fit…
Figure 10
Figure 10. Figure 10: Types in LJR. • A list of type-checker strength reduction rules, each described by a tuple ⟨𝑃, 𝑄, 𝑟⟩, where 𝑃 ⊊ T is the precondition set of types that a boxed value 𝑣 is known to have, 𝑄 ⊊ 𝑃 is the set of types to check, and 𝑟 : V → 𝑏𝑜𝑜𝑙 is the optimized function to …
Figure 11
Figure 11. Figure 11: Use of Generic IC to optimize object access. [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 14
Figure 14. Figure 14: Real disassembly of the Add bytecode in LJR interpreter [PITH_FULL_IMAGE:figures/full_fig_p012_14.png]
Figure 15
Figure 15. Figure 15: Real disassembly of a quickened GetById bytecode in LJR interpreter. The generic IC is another performance-critical API. It is fairly straightforward to lower the IC semantics to a monomorphic interpreter IC implementation: before ex￾ecuting 𝜆𝑖 , we check if the cache…
Figure 16
Figure 16. Figure 16: Real disassem￾bly of the JIT code for Add in LJR baseline JIT. Generated by [PITH_FULL_IMAGE:figures/full_fig_p015_16.png]
Figure 19
Figure 19. Figure 19: Real disassembly of the code-generator for Add in LJR’s baseline JIT. Deegen API Lowering Pipeline (for baseline JIT) C++ Bytecode Semantics Compilation to LLVM IR Identify Runtime Constants Propagate Runtime Constants Analyze Constant Range Transform Constant Express…
Figure 22
Figure 22. Figure 22: Diagram of the Deegen-generated baseline JIT and its generated JIT code. See also [PITH_FULL_IMAGE:figures/full_fig_p016_22.png]
Figure 23
Figure 23. Figure 23: Model IC with CallBr. The key observation is that the dynamic IC check chain can be viewed as a black box that takes in ICkey and outputs a branch target. After this abstraction, the function semantics becomes: we execute the logic before the IC, then execute this bla…
Figure 24
Figure 24. Figure 24: CFG analysis and IC extraction. Now that we have the CFG and the assembly label for the entry point of each 𝜆𝑒 , we can extract the implementations of the main logic and each IC stub logic ( [PITH_FULL_IMAGE:figures/full_fig_p018_24.png]
Figure 25
Figure 25. Figure 25: Interpreter logical lines of code (LLOC) comparison. [PITH_FULL_IMAGE:figures/full_fig_p019_25.png]
Figure 26
Figure 26. Figure 26: Performance comparison between LJR, LuaJIT and PUC Lua (interpreter-only mode) [PITH_FULL_IMAGE:figures/full_fig_p020_26.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 33 canonical work pages

  1. [1]

    https://doi.org/10.14778/3151113.3151114 Mozilla

    arXiv

  2. [3]

    Association for Computing Machinery

    Cinder: We didn’t start the fire (ICOOOLPS ’22). Association for Computing Machinery. https: //2022.ecoop.org/details/ICOOOLPS-2022-papers/5/Cinder-We-didn-t-start-the-fire Jeff Bezanson, Alan Edelman, Stefan Karpinski, and Viral B. Shah

    work page 2022

  3. [13]

    Association for Computing Machinery

    HPy: How To Design a C API For Optimizing Runtimes (ICOOOLPS ’22). Association for Computing Machinery. https://2022.ecoop.org/details/ICOOOLPS-2022-papers/6/HPy-How-To-Design-a-C-API-For-Optimizing- Runtimes 24 H. Xu and F. Kjolstad Yoshihiko Futamura

    work page 2022

  4. [17]

    The 2022 Graal Workshop: Science, Art, Magic: Using and Developing The Graal Compiler (April 2022)

    Operation DSL: How We Learned to Stop Worrying and Love Bytecodes again. The 2022 Graal Workshop: Science, Art, Magic: Using and Developing The Graal Compiler (April 2022). https://2022.ecoop. org/details/truffle-2022/3/Operation-DSL-How-We-Learned-to-Stop-Worrying-and-Love-Bytecodes-again Christian Humer, Christian Wimmer, Christian Wirth, Andreas Wöß, a...

    work page 2022

  5. [20]

    Two-level Just-in-Time Compilation with One Interpreter and One Engine

    Two-level Just-in-Time Compilation with One Interpreter and One Engine. arXiv:2201.09268 [cs.PL] Robert Gabriel Jakabosky and Dennis Schridde

    work page Pith review arXiv

  6. [27]

    The 2022 Graal Workshop: Science, Art, Magic: Using and Developing The Graal Compiler (April 2022)

    Truffle Interpreter Performance without the Holy Graal. The 2022 Graal Workshop: Science, Art, Magic: Using and Developing The Graal Compiler (April 2022). https: //kar.kent.ac.uk/93938/1/Truffle_Interpreter_Performance_without_the_Holy_Graal.pdf The Truffle interpreter vs Node.js interpreter/CPython/CRuby performance comparison is on page

    work page 2022

  7. [30]

    Proceedings of the VLDB Endowment 4, 9 (2011), 539–550

    Efficiently compiling efficient query plans for modern hardware. Proceedings of the VLDB Endowment 4, 9 (2011), 539–550. K. V. Nori, Sanjeev Kumar, and M. Pavan Kumar

    work page 2011

  8. [31]

    In Proceedings of the 2021 IEEE/ACM International Symposium on Code Generation and Optimization (Virtual Event, Republic of Korea) (CGO ’21)

    HHVM Jump-Start: Boosting Both Warmup and Steady-State Performance at Scale. In Proceedings of the 2021 IEEE/ACM International Symposium on Code Generation and Optimization (Virtual Event, Republic of Korea) (CGO ’21). IEEE Press, 340–350. https://doi.org/10.1109/CGO51591.2021.9370314 Matthew Weier O’Phinney

    arXiv 2021

Show all 47 references
  1. [33]

    Suggestions on implementing an efficient instruction set simulator in LuaJIT2 . LuaJIT. http://lua-users.org/ lists/lua-l/2011-02/msg00742.html Mike Pall

    2011

  2. [36]

    In Proceedings of the 11th Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (Rome, Italy) (ICOOOLPS ’16)

    Sulong - Execution of LLVM-Based Languages on the JVM: Position Paper. In Proceedings of the 11th Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (Rome, Italy) (ICOOOLPS ’16). Association for Computing Machinery, New Yor...

  3. [37]

    In Proceedings of the Ninth International Conference on Generative Programming and Component Engineering (Eindhoven, The Netherlands) (GPCE ’10)

    Lightweight Modular Staging: A Pragmatic Approach to Runtime Code Generation and Compiled DSLs. In Proceedings of the Ninth International Conference on Generative Programming and Component Engineering (Eindhoven, The Netherlands) (GPCE ’10). Association for Computing Machinery...

  4. [42]

    The Baseline Compiler Has Landed . Mozilla. https://hacks.mozilla.org/2010/03/improving-javascript- performance-with-jagermonkey/ Luke Wagner

    2010

  5. [44]

    In Proceedings of the 26th International Conference on Compiler Construction (Austin, TX, USA) (CC 2017)

    One Compiler: Deoptimization to Optimized Code. In Proceedings of the 26th International Conference on Compiler Construction (Austin, TX, USA) (CC 2017). Association for Computing Machinery, New York, NY, USA, 55–64. https://doi.org/10.1145/3033019.3033025 Thomas Würthinger, C...

    2017

  6. [45]

    InProceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software (Indianapolis, Indiana, USA) (Onward! 2013)

    One VM to Rule Them All. InProceedings of the 2013 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software (Indianapolis, Indiana, USA) (Onward! 2013). Association for Computing Machinery, New York, NY, USA, 187–204. https://doi.org/1...

    2013

  7. [46]

    In Proceedings of the 8th Symposium on Dynamic Languages (Tucson, Arizona, USA) (DLS ’12)

    Self- Optimizing AST Interpreters. In Proceedings of the 8th Symposium on Dynamic Languages (Tucson, Arizona, USA) (DLS ’12). Association for Computing Machinery, New York, NY, USA, 73–82. https://doi.org/10.1145/2384577.2384587 Haoran Xu and Fredrik Kjolstad

  8. [47]

    lhs") // An operand named

    Copy-and-Patch Compilation: A Fast Compilation Algorithm for High-Level Languages and Bytecode. Proc. ACM Program. Lang. 5, OOPSLA, Article 136 (oct 2021), 30 pages. https://doi.org/10. 1145/3485513 Deegen: A JIT-Capable VM Generator for Dynamic Languages 27 A DEEGEN API REFER...

    2021

  9. [1953]

    Classes of recursively enumerable sets and their decision problems. Trans. Amer. Math. Soc. 74 (1953), 358–366. https://api.semanticscholar.org/CorpusID:120980829 Manuel Rigger, Matthias Grimmer, and Hanspeter Mössenböck

    1953

  10. [1973]

    Threaded Code. Commun. ACM 16, 6 (jun 1973), 370–372. https://doi.org/10.1145/362248.362270 Maxwell Bernstein

    1973

  11. [1977]

    Expensive Procedure Call

    Debunking the “Expensive Procedure Call” Myth or, Procedure Call Implementations Considered Harmful or, LAMBDA: The Ultimate GOTO. In Proceedings of the 1977 Annual Conference (Seattle, Washington) (ACM ’77). ACM, New York, NY, USA, 153–162. https://doi.org/10.1145/800179.8101...

    1977

  12. [1980]

    Computer 13, 8 (1980), 38–49

    An Overview of the Production-Quality Compiler- Compiler Project. Computer 13, 8 (1980), 38–49. https://doi.org/10.1109/MC.1980.1653748 Gabriel de Quadros Ligneul

    1980

  13. [1982]

    In Proceedings of the 9th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Albuquerque, New Mexico) (POPL ’82)

    A Semantics-Directed Compiler Generator. In Proceedings of the 9th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (Albuquerque, New Mexico) (POPL ’82). Association for Computing Machinery, New York, NY, USA, 224–233. https://doi.org/10.1145/582153.582178 N...

  14. [1984]

    In Proceedings of the 1984 ACM Symposium on LISP and Functional Programming (Austin, Texas, USA) (LFP ’84)

    Compiling a Functional Language. In Proceedings of the 1984 ACM Symposium on LISP and Functional Programming (Austin, Texas, USA) (LFP ’84). Association for Computing Machinery, New York, NY, USA, 208–217. https://doi.org/10.1145/800055.802037 Kevin Casey, David Gregg, and M. ...

    1984

  15. [1989]

    In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (New Orleans, Louisiana, USA) (OOPSLA ’89)

    An Efficient Implementation of SELF a Dynamically-Typed Object-Oriented Language Based on Prototypes. In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (New Orleans, Louisiana, USA) (OOPSLA ’89). Association for Computing Machinery, N...

  16. [1991]

    ACM Trans

    Constant propagation with conditional branches. ACM Trans. Program. Lang. Syst. 13, 2 (April 1991), 181–210. https://doi.org/10.1145/103135.103136 Wikipedia

    1991

  17. [1992]

    In Proceedings of the ACM SIGPLAN 1992 Conference on Programming Language Design and Implementation (San Francisco, California, USA) (PLDI ’92)

    Debugging Optimized Code with Dynamic Deoptimization. In Proceedings of the ACM SIGPLAN 1992 Conference on Programming Language Design and Implementation (San Francisco, California, USA) (PLDI ’92). Association for Computing Machinery, New York, NY, USA, 32–43. https://doi.org...

    1992

  18. [1994]

    In Proceedings of the Ninth Annual Conference on Object-Oriented Programming Systems, Language, and Applications (Portland, Oregon, USA) (OOPSLA ’94)

    A Third-Generation SELF Implementation: Reconciling Responsiveness with Performance. In Proceedings of the Ninth Annual Conference on Object-Oriented Programming Systems, Language, and Applications (Portland, Oregon, USA) (OOPSLA ’94). Association for Computing Machinery, New ...

  19. [1997]

    InProceedings of the 1997 Symposium on Software Reusability (Boston, Massachusetts, USA) (SSR ’97)

    A framework for application generator design. InProceedings of the 1997 Symposium on Software Reusability (Boston, Massachusetts, USA) (SSR ’97). Association for Computing Machinery, New York, NY, USA, 131–135. https://doi.org/10.1145/258366.258408 Scott Thibault, Charles Cons...

    1997

  20. [2000]

    Higher-Order and Symbolic Computation 13 (09 2000)

    Static and Dynamic Program Compi- lation by Interpreter Specialization. Higher-Order and Symbolic Computation 13 (09 2000). https://doi.org/10.1023/A: 1010078412711 Laurence Tratt

    doi

  21. [2001]

    Unix Programmer’s Manual 2 (11 2001)

    Yacc: Yet Another Compiler-Compiler. Unix Programmer’s Manual 2 (11 2001). Neil Jones, Carsten Gomard, and Peter Sestoft

    2001

  22. [2002]

    Vmgen: A Generator of Efficient Virtual Machine Interpreters. Softw. Pract. Exper. 32, 3 (mar 2002), 265–294. https://doi.org/10.1002/spe.434 Tim Felgentreff

    2002 doi

  23. [2004]

    https://doi.org/10

    IEEE, San Jose, CA, USA, 75–86. https://doi.org/10. 1109/CGO.2004.1281665 Deegen: A JIT-Capable VM Generator for Dynamic Languages 25 Leverett, Cattell, Hobbs, Newcomer, Reiner, Schatz, and Wulf

    2004 arXiv

  24. [2005]

    In Proceedings of the 14th International Conference on Compiler Construction (Edinburgh, UK) (CC’05)

    Tiger – an Interpreter Generation Tool. In Proceedings of the 14th International Conference on Compiler Construction (Edinburgh, UK) (CC’05). Springer-Verlag, Berlin, Heidelberg, 246–249. https://doi.org/10.1007/978-3-540-31985-6_18 Petr Chalupa. 2019.TruffleRuby: Wrapping up ...

    doi

  25. [2009]

    LuaJIT 2.0 intellectual property disclosure and research opportunities . LuaJIT. http://lua-users.org/lists/lua- l/2009-11/msg00089.html Mike Pall

    2009

  26. [2010]

    SIGPLAN Not

    Efficient Interpretation Using Quickening. SIGPLAN Not. 45, 12 (oct 2010), 1–14. https://doi.org/10. 1145/1899661.1869633 Luca Cardelli

    2010

  27. [2011]

    Unladen Swallow Retrospective . Google. https://qinsb.blogspot.com/2011/03/unladen-swallow- retrospective.html C. Lattner and V. Adve

    2011

  28. [2012]

    The Julia Programming Language . Julia. https: //julialang.org/ B.W. Boehm, C. Abts, A.W. Brown, B.K. Clark, and S. Chulani. 2009.Software Cost Estimation with COCOMO II . Prentice Hall. https://books.google.com/books?id=cRCMQQAACAAJ Carl Friedrich Bolz and Laurence Tratt

    2009

  29. [2013]

    In Proceedings of the 7th ACM Workshop on Virtual Machines and Intermediate Languages (Indianapolis, Indiana, USA) (VMIL ’13)

    An Intermediate Representation for Speculative Optimizations in a Dynamic Compiler. In Proceedings of the 7th ACM Workshop on Virtual Machines and Intermediate Languages (Indianapolis, Indiana, USA) (VMIL ’13). Association for Computing Machinery, New York, NY, USA, 1–10. http...

  30. [2014]

    In Proceedings of the 2014 International Conference on Generative Programming: Concepts and Experiences (Västerås, Sweden) (GPCE 2014)

    A Domain-Specific Language for Building Self-Optimizing AST Interpreters. In Proceedings of the 2014 International Conference on Generative Programming: Concepts and Experiences (Västerås, Sweden) (GPCE 2014). Association for Computing Machinery, New York, NY, USA, 123–132. ht...

    2014

  31. [2015]

    SCICO (Feb

    The impact of meta-tracing on VM design and implementation. SCICO (Feb. 2015), 408–421. https://doi.org/10.1016/j.scico.2013.02.001 Carl Friedrich Bolz-Tereick

    2015 doi

  32. [2016]

    52, 2 (Nov

    Cross-language compiler benchmarking: are we fast yet? SIGPLAN Not. 52, 2 (Nov. 2016), 120–131. https://doi.org/10.1145/3093334.2989232 Stefan Marr, Octave Larose, Sophie Kaleba, and Chris Seaton

    2016

  33. [2017]

    Proceedings of the VLDB Endowment 11 (September 2017), 1–13

    Relaxed Operator Fusion for In-Memory Databases: Making Compilation, Vectorization, and Prefetching Work Together At Last. Proceedings of the VLDB Endowment 11 (September 2017), 1–13. Issue

    2017

  34. [2018]

    Implementing asm-goto support in Clang/LLVM . LLVM. https://lists.llvm.org/pipermail/llvm-dev/2018- October/127239.html LLVM

    2018

  35. [2019]

    Journal of Computer Languages 51 (2019), 261–279

    eJSTK: Building JavaScript virtual machines with customized datatypes for embedded systems. Journal of Computer Languages 51 (2019), 261–279. https://doi.org/10.1016/j.cola.2019. 01.003 Kannan Vijayan

    2019 doi

  36. [2020]

    In Proceedings of the 16th ACM SIGPLAN International Symposium on Dynamic Languages (Virtual, USA) (DLS 2020)

    Amalgamating Different JIT Compilations in a Meta-Tracing JIT Compiler Framework. In Proceedings of the 16th ACM SIGPLAN International Symposium on Dynamic Languages (Virtual, USA) (DLS 2020). Association for Computing Machinery, New York, NY, USA, 1–15. https://doi.org/10.114...

    2020

  37. [2021]

    Springer

    PHP 8 Revealed. Springer. https://link.springer.com/book/10.1007/978-1-4842-6818-6 M. Anton Ertl, David Gregg, Andreas Krall, and Bernd Paysan

    doi

  38. [2022]

    In ICS ’22: 2022 International Conference on Supercomputing, Virtual Event, USA, June 27-30, 2022 (ICS ’22) , Lawrence Rauchwerger, Kirk Cameron, Dimitrios S

    uiCA: Accurate Throughput Prediction of Basic Blocks on Recent Intel Microar- chitectures. In ICS ’22: 2022 International Conference on Supercomputing, Virtual Event, USA, June 27-30, 2022 (ICS ’22) , Lawrence Rauchwerger, Kirk Cameron, Dimitrios S. Nikolopoulos, and Dionisios...

    2022

  39. [2023]

    In Proceedings of the 38th ACM/SIGAPP Symposium on Applied Computing (Tallinn, Estonia) (SAC ’23)

    Optimizing the Order of Bytecode Handlers in Interpreters using a Genetic Algorithm. In Proceedings of the 38th ACM/SIGAPP Symposium on Applied Computing (Tallinn, Estonia) (SAC ’23). Association for Computing Machinery, New York, NY, USA, 1384–1393. https://doi.org/10.1145/35...

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.