I'm a little sad to see YJIT go down in favour of a traditional design. (Yes, YJIT isn't "deprecated" but the people working on it are now mainly working on something else. That's hardly a great place to be in.)

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.

▲

kenjin4096 2 hours ago | parent | next [-]

Tier-ups for trace-based JITs have been explored before. You can find an example here https://dl.acm.org/doi/abs/10.1145/2398857.2384630 I know LBBV isn't technically tracing, but it's quite similar, so I think similar concepts apply.

▲

tekknolagi 5 hours ago | parent | prev [-]

In that scenario, what would you hope to get out of the LBBV?

	▲	aapoalas 5 hours ago \| parent [-]
		Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here. Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation. So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.