Simple and Effective Type Check Removal through Lazy Basic Block Versioning · HackerPapers discussions

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by kenhwang

Thu, 13 Feb 2025 03:23:35 GMT

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.

Paper and discussion history. A mention is not an endorsement.

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by jacques_chester

Wed, 21 Feb 2024 15:57:19 GMT

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 to work in a team adjacent to Maxime's. [0] https://arxiv.org/abs/1411.0352

Paper and discussion history. A mention is not an endorsement.

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by whizzter

Mon, 17 Jan 2022 23:21:40 GMT

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 constraints of practical dynlang JITs often differ a bit from those for statically typed languages. The JITs for statically typed languages are often fairly "straightforward" since the basic/primitive types are often known, and with the exception for dispatch optimizations, many large wins comes from register allocation,etc. A…

Paper and discussion history. A mention is not an endorsement.

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by PeCaN

Wed, 16 Mar 2016 16:01:41 GMT

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. http://arxiv.org/abs/1411.0352

Paper and discussion history. A mention is not an endorsement.

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by PeCaN

Tue, 22 Dec 2015 17:52:59 GMT

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 because you expect to not bail out of this block version). This way you wouldn't have to warm up for type inference. If the program type-checks you can get almost static type performance. Dart also has an advantage in app startup time since you can just load your snapshot. -- 1: I'm not familiar with the internals of the…

Paper and discussion history. A mention is not an endorsement.

Simple and Effective Type Check Removal through Lazy Basic Block Versioning — mentioned by Veedrac

Mon, 16 Feb 2015 06:15:25 GMT

> 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.

Paper and discussion history. A mention is not an endorsement.