HackerPapers

arXiv:1411.0352cs.PL

Simple and Effective Type Check Removal through Lazy Basic Block Versioning

Maxime Chevalier-Boisvert, Marc Feeley

Abstract

Dynamically typed programming languages such as JavaScript and Python defer type checking to run time. In order to maximize performance, dynamic language VM implementations must attempt to eliminate redundant dynamic type checks. However, type inference analyses are often costly and involve tradeoffs between compilation time and resulting precision. This has lead to the creation of increasingly complex multi-tiered VM architectures. This paper introduces lazy basic block versioning, a simple JIT compilation technique which effectively removes redundant type checks from critical code paths. This novel approach lazily generates type-specialized versions of basic blocks on-the-fly while propagating context-dependent type information. This does not require the use of costly program analyses, is not restricted by the precision limitations of traditional type analyses and avoids the implementation complexity of speculative optimization techniques. We have implemented intraprocedural lazy basic block versioning in a JavaScript JIT compiler. This approach is compared with a classical flow-based type analysis. Lazy basic block versioning performs as well or better on all benchmarks. On average, 71% of type tests are eliminated, yielding speedups of up to 50%. We also show that our implementation generates more efficient machine code than TraceMonkey, a tracing JIT compiler for JavaScript, on several benchmarks. The combination of implementation simplicity, low algorithmic complexity and good run time performance makes basic block versioning attractive for baseline JIT compilers.

arXiv comments
Journal reference
DOI
Subjects
cs.PLProgramming Languages

On Hacker News

Linked by 5 identifiable commenters in 6 comments across 6 threads, from Feb 2015 to Feb 2025.

Comments linking this paper, per year.

Discussed in comments6 threads

  1. Tiny JITs for a Faster FFI 1 comment
    • I believe this is the paper that started it all (there are a couple of follow up papers): https://arxiv.org/pdf/1411.0352v1 The author was eventually hired to develop YJIT.

      kenhwangView on HNParent context

    • For those wondering why an interview with Maxime is interesting: Maxime coinvented the Basic Block Versioning approach to JITs[0] during her studies. It's the basis for YJIT, which has landed big speedups for the C Ruby implementation over the past few years. Disclosure: I used…

      jacques_chesterView on HNParent context

  2. Ruby: Porting YJIT to Rust 1 comment
    • Afaik the only ones that's somewhat successfully used LLVM for a dynlang JIT is the Safari guys, and iirc that one was only for the highest optimization level (and that is an important hint on their direction and one that most dynlang JIT's should head). The goals and…

      whizzterView on HNParent context

    • Because with 80%+ unused code, your instruction cache is gonna choke. Also JITs can remove many more type checks, because it knows when a check would be redundant. See e.g. Lazy Basic Block Versioning[1], but existing tracing JITs do quite well also. 1.…

      PeCaNView on HNParent context

  3. Kotlin for Android Developers 1 comment
    • Dart's performance is pretty good; its authors are VM geniuses. If it doesn't already[1], it could leverage the optional typing for block versioning on initial compilation, and assume that version is correct most of the time (generating the most-optimized version initially…

      PeCaNView on HNParent context

    • > I wonder if there aren't code size explosion problems, though. The paper (http://arxiv.org/abs/1411.0352) covers this on page 8. You're likely looking at tiny code-size increases overall.

      VeedracView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.