Pith. sign in

REVIEW 4 major objections 7 minor 40 references

A Lightweight Method for Generating Multi-Tier JIT Compilation Virtual Machine in a Meta-Tracing Compiler Framework

T0 review · 4 major / 7 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read By embedding directives and compile-time operations in interpreter definitions, the paper generates a multi-tier JIT virtual machine on RPython: warm-up improves 15% while peak performance drops about 5%.

desk verdict 2SOM gives RPython-based VMs a cheap tier-1 JIT using only interpreter annotations; the measurements are honest but the evaluation rests on a synthetic workload and the trickiest correctness argument is not demonstrated. read the letter →

arxiv 2504.17460 v3 pith:SF5DZ5YK submitted 2025-04-24 cs.PL

Yusuke Izawa , Hidehiko Masuhara , Carl Friedrich Bolz-Tereick This is my paper · ORCID
classification cs.PL
keywords multi-tierJITcompilationmeta-tracingcompilerRPythonthreadedcodegenerationshallowtracinginlinecachingvirtualmachineSimpleObject
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

This paper claims that a meta-compiler framework such as RPython can produce a multi-tier JIT virtual machine without implementing a second compiler backend. The trick is to treat interpreter definitions as compilation specifications: adding small directives makes the existing heavyweight tracing compiler generate a fast, unoptimized tier-1 threaded code, while a profiler and switcher embedded in the interpreter move hot loops to the tier-2 tracing compiler. The authors validate this with 2SOM, a two-tier version of the Simple Object Machine, measuring a 15% warm-up improvement with only about 5% peak-performance loss against the same VM using only tracing JIT. If correct, any RPython-based interpreter can gain tiered compilation at low engineering cost, making short-lived and interactive programs start faster.

What carries the argument

The load-bearing object is the annotated threaded-code trace: a sequence of call operations to bytecode handlers, with guards, labels, and finish operations, which RPython's existing compiler backend turns into native subroutine-threaded code. Shallow tracing is the mechanism that makes these traces safe: every handler gets a dummy flag; while we_are_jitted() holds during trace collection, the handler bodies are replaced by stubs that return immediately, and after compilation the stubs are swapped for real handlers. Direct calls with inline caching supply the second mechanism, converting the runtime type check and method lookup into guard_ptr_eq plus a direct call_assembler instruction. The profiler, a backward-jump counter in the lightweight interpreter, and the interpreter switcher, raising and catching ContinueTier2 with the live frame, are the components that connect the two tiers.

What would settle it

Take the Section 5 array example and run it under tier-1-only threaded code: if the speculative trace that includes the else branch's clear call produces a different final array or result than interpreter execution on the same input, shallow tracing has failed to preserve semantics. A sharper version adds a handler that raises an RPython-level exception when executed, records it in a thread, and checks whether the compiled tier-1 code raises at the same point and with the same frame state as the interpreter.

Watch

Extended reading notes

Core claim

The paper's central claim is that a meta-compiler framework can generate a multi-tier JIT VM by reusing its heavyweight backend as the generator of a lightweight tier. Specifically, by placing enable_threaded_code annotations on bytecode-handler functions and by adding compile-time operations that record and check receiver types, the RPython tracer is driven to emit subroutine-threaded code in which every bytecode becomes a direct call to a handler; shallow tracing keeps those calls' bodies from executing during trace collection, so tracing both branches of a branch cannot corrupt interpreter state, and inline caching turns the resulting indirect calls into guarded direct calls. The same interpreter definitions then provide a profiler, a per-program-counter counter, and a switcher, an exception carrying the frame, that hand hot loops to the existing tracing JIT. The paper validates this with 2SOM, a two-tier Simple Object Machine, reporting about 15% faster warm-up and about 5% lower peak performance compared with an RPython-based tracing-JIT-only VM.

Load-bearing premise

The whole construction assumes that a stub call recorded during shallow tracing can be replaced by the real handler in the compiled threaded code without changing observable behavior; if a skipped handler would have influenced control flow, the stack, or raised an exception at trace time, the tier-1 code can diverge from the interpreter.

Editorial extensions

If this is right

  • If the paper's approach is right, RPython-based VMs obtain a first JIT tier without writing a new compiler backend.
  • Warm-up improves by about 15% over tracing-JIT-only on realistic workloads, so short-lived and interactive programs reach full speed sooner.
  • Peak performance stays within about 5% of the tracing-only baseline on the synthesized workload, meaning the tier-1, profiler, and switcher overhead is modest.
  • The tier-1 threaded code itself runs about 10% faster than interpreter execution, so it is a useful execution mode even before tier-2 kicks in.
  • The profiler and transition logic are expressed as interpreter definitions, which keeps implementation cost low and makes the tier switch a VM-level feature rather than a backend feature.

Reading between the lines

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

  • Inference: The same two-tier recipe should extend to more than two tiers by stacking interpreter variants with progressively more aggressive annotations, provided each tier's trace stays within RPython's intermediate representation.
  • Inference: The paper's self-noted limitation that tier-1 does not handle handlers that raise RPython-level exceptions suggests the technique transfers most directly to languages with exception-free bytecode handlers or with zero-cost-exception mechanisms; a testable extension is to add one such handler to 2SOM and observe whether compiled tier-1 code throws at the wrong point.
  • Inference: The synthesized-benchmark methodology, which matches DaCapo's method-call-rank distribution, is itself reusable for future JIT studies comparing warm-up on small VMs.
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

4 major / 7 minor

Summary. The paper proposes a methodology for adding a lightweight first-tier compiler to VMs generated by the RPython meta-tracing framework. Rather than modifying RPython's JIT backend, the authors embed directives and compile-time operations in interpreter definitions so that RPython generates a tier-1 subroutine-threaded-code generator alongside its existing tier-2 tracing JIT compiler. The approach is validated by 2SOM, a two-tier Simple Object Machine, which first runs methods through generated threaded code and then, for loops whose back-edge count exceeds a fixed threshold, switches to the tracing JIT. The paper reports about 15% improvement in warm-up performance and about 5% peak-performance degradation relative to tracing-JIT-only execution, and further reports that two optimizations (shallow tracing and direct calls with inline caching) make the threaded-code tier about 10% faster than interpreter-only execution. The evaluation uses a synthesized workload constructed by concatenating SOM benchmarks with manually tuned iteration counts chosen to mimic the method-invocation rank distribution of DaCapo, and it uses ReBench for measurement.

Significance. If the correctness and robustness issues are resolved, this is a useful contribution to VM implementation practice. The central idea of reusing an existing heavyweight JIT backend as a lightweight compiler by changing only interpreter definitions is elegant and has the potential to reduce engineering effort for multi-tier JIT support in RPython-based language implementations. The paper provides a concrete implementation (2SOM), released source code and modified PyPy artifacts, a measurement methodology based on ReBench, and statistical testing of the warm-up claims. The synthesized-workload construction is a creative attempt to obtain a DaCapo-like workload for a small language, though its manual tuning needs scrutiny. The paper does not contain machine-checked proofs, but it is an engineering/technique paper; the main weakness is that the correctness of the new shallow-tracing mechanism is argued informally and is not backed by differential testing, and the headline performance numbers rest on unswept thresholds and hand-tuned workloads.

major comments (4)
  1. [5.2.1, Listings 15-16] The soundness of shallow tracing rests on the assumption that placeholder-initialized call results, such as i1 = call(handler_LE, p0, True), remain opaque runtime values when the RPython optimizer processes the trace. The paper never states or verifies this property, and it provides no jit-log output or differential test showing that guard_false(i1) survives optimization as a runtime branch on the real result of the skipped handler rather than being constant-folded to the default 0. If the placeholder were folded, the compiled tier-1 code would silently execute the fall-through path for every conditional whose condition is produced by a skipped handler. Please either provide an implementation-level argument that non-inlined call operations on non-constant red variables are never folded by the RPython optimizer, or add a differential correctness test comparing tier-1 threaded code against the interpreter on programs with conditionals and side effects. This concern is reinforced by the paper's own admission in Section 8 (challenge b) that the current tier-1 compiler cannot trace handlers that raise RPython-level exceptions; the correctness claim should explicitly state this restriction.
  2. [6.1, Listing 10] The evaluation fixes HOT_THRESHOLD at 1000 and never sweeps it. The headline trade-off (about 15% warm-up gain for about 5% peak loss) is therefore measured at a single operating point, and without a sensitivity analysis we cannot tell whether the gain is robust or a tuning artifact. I request a sweep over HOT_THRESHOLD values (for example, 100, 300, 1000, 3000, and 10000) with both warm-up and peak performance reported at each value.
  3. [A.1, 6.1] The synthesized workload construction manually tunes internal iteration counts until the rank-invocation correlation is close to R2 = 0.98. This manual step is a free parameter of the evaluation, and the headline warm-up result depends on it. The exact iteration counts and the tuning procedure should be published, and the warm-up conclusion should be checked for stability under perturbations of the counts, or at least under a second independently constructed workload.
  4. [4.2.3, Figure 6] The transition mechanism is not specified at the level needed to establish correctness. The profiler raises ContinueTier2 from code compiled out of the lightweight interpreter, but the paper does not explain how an RPython-level exception can unwind out of generated machine code, how nested threaded-code frames are reconstructed when control passes to tracing_interpret, or what call_assembler does when the target method has not yet been compiled. Please specify the runtime representation of the continuation and the behavior of call_assembler on uncompiled methods, and test the transition in programs with nested calls inside hot loops.
minor comments (7)
  1. [Abstract and Section 6.3] The abstract and introduction state a 5% peak-performance degradation, but Figure 11 reports about 3% against tracing JIT and about 5% against tracing JIT with a higher threshold, while Figure 12 reports about 7% for SOM microbenchmarks; please specify which comparison the 5% figure refers to and use consistent numbers throughout the paper.
  2. [6.1] The p-values are reported as percentages (0.0314% and 2.151%); use conventional p-value notation or clearly explain the transformation.
  3. [6.1] The description 'we measure the elapsed time obtained from the first iteration of each program and repeat this measurement 2,000 times' is ambiguous; clarify whether each repetition starts a fresh VM process and what exactly constitutes the first iteration.
  4. [5.2.1, Listing 15] The comment in Listing 15 says we_are_jitted() 'returns true while tracing and executing machine code', which contradicts Section 5.2's statement that the dummy flag is turned to False when the compiled code executes; clarify that the stub-to-real-handler replacement removes the dummy call path from the final machine code.
  5. [4.1] The text says 'using the program shown in Figure 5 and the traces presented in Figure 5'; the first reference should likely be Figure 1, and the two captions in Figure 5 appear to be swapped.
  6. [Listing 11] Listing 11 contains the typo 'interpet_switcher', and the exception name is written inconsistently as ContinueTier2, ContinueInTier2, and ContinueTier2; please unify the spelling.
  7. [Listing 14] Listing 14 contains a stray '# ... XXX ...' comment that appears to be a leftover editing artifact.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's claims are implemented and measured, not derived from their own inputs.

full rationale

The paper's central claim is that embedding directives and compile-time operations in interpreter definitions lets RPython's existing tracing backend generate a lightweight tier-1 threaded-code compiler, with 2SOM as a validating implementation. This claim is not circular: the tier-1 generator is concretely constructed from interpreter annotations (Listings 8, 10, 11, 17, 18, and 21) and its behavior is evaluated against RPython's stock tracing JIT and TruffleSOM. The self-citation to Izawa et al. [24] supplies the prior threaded-code generation technique; that result is peer-reviewed, code-reproduced, and independently published, and the paper's own contributions are the new shallow-tracing and inline-caching mechanisms, which are described directly rather than imported by citation. The headline warm-up improvement of approximately 15% and peak degradation of approximately 5% are measured outcomes from a synthesized benchmark; no fitted parameter is renamed as a prediction, and the benchmark construction is explicit and separate from the measurement of the mechanism. The paper's own Section 8 limitation, that the current tier-1 compiler cannot trace handlers that raise RPython-level exceptions, narrows the generality of the approach but does not make any result equivalent to its inputs. The remaining risk, that placeholder-initialized results of skipped handlers (e.g., 'i1 is initialized with a default value (0)' in Listing 16) must remain opaque to the RPython optimizer for guards like guard_false(i1) to test real runtime values, is a soundness assumption and a potential correctness bug, not a circularity, because the evaluation could independently succeed or fail under that assumption. No equations or derivations in the paper reduce to fitted values or to definitions of the claimed outputs, so no circular step can be exhibited.

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

The central performance claims rest on the hand-chosen HOT_THRESHOLD and on synthesized workloads adjusted to match DaCapo's method-call distribution; the correctness of the tier-1 generator rests on the soundness of shallow tracing, which is assumed without a formal proof.

free parameters (2)
  • HOT_THRESHOLD = 1000
    Backward-jump count that triggers tier-2 compilation; chosen by hand, not swept, and directly shapes warm-up vs peak trade-off (Section 4.2.2, Listing 10).
  • Synthesized benchmark iteration counts = tuned per subprogram (values not listed)
    Internal iteration counts of 20 subprograms are manually adjusted so that the method-call/rank correlation approximates DaCapo's R-squared around 0.98; this tunes the evaluation workload (Appendix A).
assumptions (3)
  • domain assumption RPython's meta-tracing JIT can be driven by interpreter annotations to emit unoptimized threaded code while preserving semantics via shallow tracing.
    The central technique assumes the tracing engine records calls without executing handler bodies and that replacing stubs with real handlers at compile time is sound (Section 5.2.1).
  • domain assumption The DaCapo method-call frequency distribution (power-law rank) is representative of real-world workloads for evaluating JIT warm-up.
    The synthesized benchmark design is justified by R-squared values above 0.98 on DaCapo and PyPy benchmarks, but this is a workload assumption, not a proof (Appendix A).
  • domain assumption The custom PyPy modifications used to build 2SOM do not alter tier-2 tracing JIT performance relative to the baseline measured.
    Comparisons against 'tracing JIT' assume the customized PyPy's JIT is equivalent to the stock one used as baseline; no explicit verification is reported (Section 6.1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Lightweight Method for Generating Multi-Tier JIT Compilation Virtual Machine in a Meta-Tracing Compiler Framework." pith.science (2026). https://pith.science/paper/SF5DZ5YK

@misc{pith2026250417460,
  author       = {Pith},
  title        = {Pith review of: A Lightweight Method for Generating Multi-Tier JIT Compilation Virtual Machine in a Meta-Tracing Compiler Framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SF5DZ5YK}},
  note         = {Machine review of arXiv:2504.17460}
}
read the original abstract

Meta-compiler frameworks, such as RPython and Graal/Truffle, generate high-performance virtual machines (VMs) from interpreter definitions. Although they generate VMs with high-quality just-in-time (JIT) compilers, they still lack an important feature that dedicated VMs (i.e., VMs that are developed for specific languages) have, namely \emph{multi-tier compilation}. Multi-tier compilation uses light-weight compilers at early stages and highly-optimizing compilers at later stages in order to balance between compilation overheads and code quality. We propose a novel approach to enabling multi-tier compilation in the VMs generated by a meta-compiler framework. Instead of extending the JIT compiler backend of the framework, our approach drives an existing (heavyweight) compiler backend in the framework to quickly generate unoptimized native code by merely embedding directives and compile-time operations into interpreter definitions. As a validation of the approach, we developed 2SOM, a Simple Object Machine with a two-tier JIT compiler based on RPython. 2SOM first applies the tier-1 threaded code generator that is generated by our proposed technique, then, to the loops that exceed a threshold, applies the tier-2 tracing JIT compiler that is generated by the original RPython framework. Our performance evaluation that runs a program with a realistic workload showed that 2SOM improved, when compared against an RPython-based VM, warm-up performance by 15\%, with merely a 5\% reduction in peak performance.

Figures

Figures reproduced from arXiv: 2504.17460 by the authors.

Figure 14
Figure 14. The experimental program consists of 20 subprograms. These subprograms are executed sequentially from top to bottom, with each subprogram assigned a predetermined number of iterations within the experimental program. To generate the set of 20 experiment programs, the execution order of the subprograms is randomly shuffled. Specifically, a base subprogram order is first determined. Then, by shuffling the execution or… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 30 canonical work pages

  1. [1]

    Matthew Arnold, Stephen Fink, David Grove, Michael Hind, and Peter F. Sweeney. Adaptive O ptimization in the J alapeño JVM . In Proceedings of the 15th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications , OOPSLA 2000, pages 47--65. Association for Computing Machinery, 2000. https://doi.org/10.1145/353171.353175 doi...

    work page arXiv

  2. [2]

    Dynamo: a Transparent Dynamic Optimization System

    Vasanth Bala, Evelyn Duesterwald, and Sanjeev Banerjia. Dynamo: a Transparent Dynamic Optimization System . In Proceedings of the ACM SIGPLAN 2000 Conference on Programming Language Design and Implementation , 2000. https://doi.org/10.1145/349299.349303 doi:10.1145/349299.349303

    work page arXiv

  3. [3]

    SPUR : A T race-based JIT C ompiler for CIL

    Michael Bebenita, Florian Brandner, Manuel Fahndrich, Francesco Logozzo, Wolfram Schulte, Nikolai Tillmann, and Herman Venter. SPUR : A T race-based JIT C ompiler for CIL . In Proceedings of the ACM International Conference on Object Oriented Programming Systems Languages and Applications , OOPSLA 2010, pages 708--725. Association for Computing Machinery,...

    work page arXiv 2010

  4. [4]

    James R. Bell. Threaded code. Commun. ACM , 16(6):370--372, 1973. https://doi.org/10.1145/362248.362270 doi:10.1145/362248.362270

    arXiv 1973

  5. [5]

    Blackburn, Robin Garner, Chris Hoffmann, Asjad M

    Stephen M. Blackburn, Robin Garner, Chris Hoffmann, Asjad M. Khang, Kathryn S. McKinley, Rotem Bentzur, Amer Diwan, Daniel Feinberg, Daniel Frampton, Samuel Z. Guyer, Martin Hirzel, Antony Hosking, Maria Jump, Han Lee, J. Eliot B. Moss, Aashish Phansalkar, Darko Stefanović, Thomas VanDrunen, Daniel von Dincklage, and Ben Wiedermann. The D a C apo B enchma...

    arXiv 2006

  6. [6]

    Tracing the Meta-Level: PyPy's Tracing JIT Compiler

    Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski, and Armin Rigo. Tracing the Meta-Level: PyPy's Tracing JIT Compiler . In Proceedings of the 4th Workshop on the Implementation, Compilation, Optimization of Object-Oriented Languages and Programming Systems , ICOOOLPS 2009, page 18–25, New York, NY, USA, 2009. Association for Computing Machinery. http...

    arXiv 2009

  7. [7]

    The Impact of Meta-tracing on VM Design and Implementation

    Carl Friedrich Bolz and Laurence Tratt. The Impact of Meta-tracing on VM Design and Implementation . Science of Computer Programming , 98:408--421, 2015. Special Issue on Advances in Dynamic Languages. https://doi.org/10.1016/j.scico.2013.02.001 doi:10.1016/j.scico.2013.02.001

    doi:10.1016/j.scico.2013.02.001 2015

  8. [8]

    Zero cost exception handling

    CPython . Zero cost exception handling. URL: https://github.com/python/cpython/blob/main/InternalDocs/exception_handling.md

    work page

Show all 40 references
  1. [9]

    L ife in the F ast F orth L ane

    Charles Curley. L ife in the F ast F orth L ane. Forth Dimensions , 14(4):6--12, Januarly/Feburary 1993

    1993

  2. [10]

    O ptimizing in a BSR/JSR T hreaded F orth

    Charles Curley. O ptimizing in a BSR/JSR T hreaded F orth. Forth Dimensions , 14(5):21--26, March/April 1993

    1993

  3. [11]

    Peter Deutsch and Allan M

    L. Peter Deutsch and Allan M. Schiffman. Efficient implementation of the smalltalk-80 system. In Proceedings of the 11th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages , POPL '84, pages 297–--302, New York, NY, USA, 1984. Association for Computing Machiner...

    1984

  4. [12]

    Robert B.K. Dewar. Indirect T hreaded C ode. Communications of the ACM , 18(6):330--331, June 1975

    1975

  5. [13]

    Open J9 : Unleash the power of java, 2017

    Eclipse Foundation . Open J9 : Unleash the power of java, 2017. URL: https://www.eclipse.org/openj9/

    2017

  6. [14]

    Anton Ertl and David Gregg

    M. Anton Ertl and David Gregg . The Structure and Performance of Efficient Interpreters . Journal of Instruction-level Parallelism , 5, November 2003

    2003

  7. [15]

    How to Build a High-Performance VM for Squeak/Smalltalk in Your Spare Time: An Experience Report of Using the RPython Toolchain

    Tim Felgentreff, Tobias Pape, Patrick Rein, and Robert Hirschfeld. How to Build a High-Performance VM for Squeak/Smalltalk in Your Spare Time: An Experience Report of Using the RPython Toolchain . In Proceedings of the 11th Edition of the International Workshop on Smalltalk Te...

  8. [16]

    Haghighat, Blake Kaplan, Graydon Hoare, Boris Zbarsky, Jason Orendorff, Jesse Ruderman, Edwin W

    Andreas Gal, Brendan Eich, Mike Shaver, David Anderson, David Mandelin, Mohammad R. Haghighat, Blake Kaplan, Graydon Hoare, Boris Zbarsky, Jason Orendorff, Jesse Ruderman, Edwin W. Smith, Rick Reitmaier, Michael Bebenita, Mason Chang, and Michael Franz. Trace-Based Just-in-Tim...

    2009

  9. [17]

    Probst, and Michael Franz

    Andreas Gal, Christian W. Probst, and Michael Franz. HotpathVM: An Effective JIT Compiler for Resource-Constrained Devices . In Proceedings of the 2nd International Conference on Virtual Execution Environments , VEE '06, pages 144--153. Association for Computing Machinery, 200...

    2006

  10. [18]

    Google’s High-performance Open Source JavaScript and WebAssembly Engine , 2015

    Google. Google’s High-performance Open Source JavaScript and WebAssembly Engine , 2015. URL: https://v8.dev/

    2015

  11. [19]

    The som family: Virtual machines for teaching and research

    Michael Haupt, Robert Hirschfeld, Tobias Pape, Gregor Gabrysiak, Stefan Marr, Arne Bergmann, Arvid Heise, Matthias Kleine, and Robert Krahn. The som family: Virtual machines for teaching and research. In Proceedings of the Fifteenth Annual Conference on Innovation and Technolo...

    2010

  12. [20]

    Optimizing dynamically-typed object-oriented languages with polymorphic inline caches

    Urs Hölzle, Craig Chambers, and David Ungar. Optimizing dynamically-typed object-oriented languages with polymorphic inline caches. In Pierre America, editor, ECOOP'91 European Conference on Object-Oriented Programming , pages 21--38. Springer Berlin Heidelberg, 1991

    1991

  13. [21]

    2SOM: A Two-Level Simple Object Machine , April 2025

    Yusuke Izawa. 2SOM: A Two-Level Simple Object Machine , April 2025. Version 1.0. https://doi.org/10.5281/zenodo.15286979 doi:10.5281/zenodo.15286979

    2025 doi

  14. [22]

    Customized PyPy for Threaded Code Generation , April 2025

    Yusuke Izawa. Customized PyPy for Threaded Code Generation , April 2025. Version 1.0. https://doi.org/10.5281/zenodo.15287001 doi:10.5281/zenodo.15287001

    2025 doi

  15. [23]

    RPython Extension that Enables a Monotonic Clock , April 2025

    Yusuke Izawa. RPython Extension that Enables a Monotonic Clock , April 2025. Version 1.0. https://doi.org/10.5281/zenodo.15286954 doi:10.5281/zenodo.15286954

    2025 doi

  16. [24]

    Threaded Code Generation with a Meta-Tracing JIT Compiler

    Yusuke Izawa, Hidehiko Masuhara, Carl Friedrich Bolz-Tereick, and Youyou Cong. Threaded Code Generation with a Meta-Tracing JIT Compiler . Journal of Object Technology , 21(2):a1, 2022. https://doi.org/10.5381/jot.2022.21.2.a1 doi:10.5381/jot.2022.21.2.a1

    2022 doi

  17. [25]

    Design of the J ava H ot S pot C lient C ompiler for J ava 6

    Thomas Kotzmann, Christian Wimmer, Hanspeter Mössenböck, Thomas Rodriguez, Kenneth Russell, and David Cox. Design of the J ava H ot S pot C lient C ompiler for J ava 6. ACM Trans. Archit. Code Optim. , 5(1), 2008-05. https://doi.org/10.1145/1369396.1370017 doi:10.1145/1369396.1370017

    2008

  18. [26]

    PySOM : A S imple O bject M achime S malltalk implemented in P ython, 2013

    Stefan Marr. PySOM : A S imple O bject M achime S malltalk implemented in P ython, 2013. URL: https://github.com/smarr/PySOM

    2013

  19. [27]

    Som B enchmarks, 2013

    Stefan Marr. Som B enchmarks, 2013. URL: https://github.com/SOM-st/SOM/tree/9c04914f800dc3ccbfaa1dc8fcf78cc5714549a4/Examples/Benchmarks

    2013

  20. [28]

    ReBench: Execute and Document Benchmarks Reproducibly , August 2018

    Stefan Marr. ReBench: Execute and Document Benchmarks Reproducibly , August 2018. Version 1.0. https://doi.org/10.5281/zenodo.1311762 doi:10.5281/zenodo.1311762

    2018 doi

  21. [29]

    Cross-language compiler benchmarking: Are we fast yet? In Proceedings of the 12th Symposium on Dynamic Languages , DLS 2016, pages 120--131

    Stefan Marr, Benoit Daloze, and Hanspeter Mössenböck. Cross-language compiler benchmarking: Are we fast yet? In Proceedings of the 12th Symposium on Dynamic Languages , DLS 2016, pages 120--131. Association for Computing Machinery, 2016. https://doi.org/10.1145/2989225.2989232...

    2016

  22. [30]

    Graalsqueak: Toward a smalltalk-based tooling platform for polyglot programming

    Fabio Niephaus, Tim Felgentreff, and Robert Hirschfeld. Graalsqueak: Toward a smalltalk-based tooling platform for polyglot programming. In Proceedings of the 16th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes , MPLR 2019, pages 14--26. ACM...

    2019

  23. [31]

    The Java Hotspot Server Compiler

    Michael Paleczny, Christopher Vick, and Cliff Click. The Java Hotspot Server Compiler . In Proceedings of the 2001 Symposium on Java Virtual Machine Research and Technology Symposium - Volume 1 , JVM 2001, page 1. USENIX Association, 2001

    2001

  24. [32]

    L anguage-independent storage strategies for tracing-jit-based virtual machines

    Tobias Pape, Tim Felgentreff, Robert Hirschfeld, Anton Gulenko, and Carl Friedrich Bolz. L anguage-independent storage strategies for tracing-jit-based virtual machines. In Proceedings of the 11th Symposium on Dynamic Languages , DLS 2015, pages 104--–113, New York, NY, USA, 2...

    2015

  25. [33]

    Speculation in JavaScriptCore , 2020

    Fillip Pizlo. Speculation in JavaScriptCore , 2020. URL: https://webkit.org/blog/10308/speculation-in-javascriptcore/

    2020

  26. [34]

    Multi- T ier C ompilation in G raal VM , 2021

    Aleksandar Prokopec. Multi- T ier C ompilation in G raal VM , 2021. URL: https://medium.com/graalvm/multi-tier-compilation-in-graalvm-5fbc65f92402

    2021

  27. [35]

    Renaissance: a modern benchmark suite for parallel applications on the jvm

    Aleksandar Prokopec, Andrea Ros\` a , David Leopoldseder, Gilles Duboscq, Petr T u ma, Martin Studener, Lubom\' r Bulej, Yudi Zheng, Alex Villaz\' o n, Doug Simon, Thomas W\" u rthinger, and Walter Binder. Renaissance: a modern benchmark suite for parallel applications on the ...

    2019

  28. [36]

    P y P y's A pproach to V irtual M achine C onstruction

    Armin Rigo and Samuele Pedroni. P y P y's A pproach to V irtual M achine C onstruction. In Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications , OOPSLA 2006, pages 944--953. Association for Computing Machinery, 2006. ...

    2006

  29. [37]

    Van De Vanter, Mick Jordan, Laurent Daynès, and Douglas Simon

    Christian Wimmer, Michael Haupt, Michael L. Van De Vanter, Mick Jordan, Laurent Daynès, and Douglas Simon. Maxine: An Approachable Virtual Machine for, and in, Java . ACM Trans. Archit. Code Optim. , 9(4), January 2013. https://doi.org/10.1145/2400682.2400689 doi:10.1145/24006...

    2013

  30. [38]

    P ractical P artial E valuation for H igh-performance D ynamic L anguage R untimes

    Thomas Würthinger, Christian Wimmer, Christian Humer, Andreas Wöß, Lukas Stadler, Chris Seaton, Gilles Duboscq, Doug Simon, and Matthias Grimmer. P ractical P artial E valuation for H igh-performance D ynamic L anguage R untimes. In Proceedings of the 38th ACM SIGPLAN Conferen...

    2017

  31. [39]

    Self- O ptimizing AST I nterpreters

    Thomas Würthinger, Andreas Wöundefined, Lukas Stadler, Gilles Duboscq, Doug Simon, and Christian Wimmer. Self- O ptimizing AST I nterpreters. In Proceedings of the 8th Symposium on Dynamic Languages , DLS 2012, pages 73--82. Association for Computing Machinery, 2012. https://d...

    2012

  32. [40]

    Copy-and-Patch Compilation: A Fast Compilation Algorithm for High-Level Languages and Bytecode

    Haoran Xu and Fredrik Kjolstad. Copy-and-Patch Compilation: A Fast Compilation Algorithm for High-Level Languages and Bytecode . Proc. ACM Program. Lang. , 5(OOPSLA), 2021. https://doi.org/10.1145/3485513 doi:10.1145/3485513

    2021 doi

Pith tools

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