> This meant that the code we were running had to continue to have the same preconditions (expected types, no method redefinitions, etc) or the JIT would safely abort. Now, we can side-exit and use this feature liberally.

> For example, we gracefully handle the phase transition from integer to string; a guard instruction fails and transfers control to the interpreter.

> (example showing add of two strings omitted)

What is the difference between the JIT safely aborting and the JIT returning control to the interpreter? Or does the JIT abort mean the entire app aborts (i.e. I presumed JIT aborting means continuing on the interpreter anyway?)

(Also, why would you want the code that uses the incorrect types to succeed? Isn’t abort of the whole unit of execution the right answer here, anyway?)

Also, what's the long-term plan for YJIT.

One thing that's struck me with the new code is that's its so easy to follow compared to rails. It's like two different extremes on the implicit-explicit spectrum. Yet it's not like I have tons more boilerplate code now, I think I have maybe 10 or 20% more SLOC than before.

I'll probably do this with my other rails apps as well.

I'm personally quite interested in trying out an LBBV JIT for JavaScript, following in Chevalier-Boisvert's Higgs engine's footsteps. The note about a traditional method JIT giving more code for the compiler to work with does ring very true, but I'd just like to see more variety in the compiler and JIT world.

Like: perhaps it would be possible to conjoin (say) an LBBV with a SoN compiler such that LBBV takes care of the quick, basic compilation and leaves behind enough data such that a SoN compiler can be put to use on the whole-method result once the whole method has been deemed hot enough? This is perhaps a totally ridiculous idea, but it's the kind of idea that will never get explored in a world with only traditional method JITs.