You don't have to maintain identical stack layouts, just be able to translate between frame formats at transitions. Most of the necessary semantics can be expressed as a function call. Figure out what JS values are live across the transition point, and pass them as arguments to a function call which transitions to the interpreter, which proceeds using those values. That can be done without any changes to LLVM, although obviously the code patching can't, and its more efficient not to require values to be shuffled into argument registers. Keeping things updated when the target function is inlined is also tricky. But overall its not as invasive a change to LLVM as you'd think. See: A Modular Approach to On-Stack Replacement in LLVM, https://www.google.com/url?sa=t&source=web&rct=j&ei=IrByU5Hx....
Whoops, I read further down and saw that you posted this link hours before me.
And it's not just two engines, but four, with at least one of them using the amount of available executable memory to choose whether to switch between them.
I know WebKit has tons of tests, but there must be some truly hairy bugs in that code. Does anybody know how they exercise the various optimize/deoptimize steps?
One neat testing strategy is to artificially lower counter used to tier up. Instead of using 1000 for DFG and 100000 for FTL, use something like 10 for DFG and 100 for FTL. This will cause lots of opt/deopt stress and can discover correctness bugs which may hide in more normal executions.
Re:Introducing the WebKit FTL JIT
by InclinedPlane on Tuesday May 13, 2014 @07:31PM
(#7741253)
Indeed. Although, to be honest, I'd expected such technology to be the norm for most interpreted/compiled languages at this point.
It turns out that instrumentation and optimization is actually a harder problem than one would think, which makes a lot of rather nifty technology farther out of reach than it otherwise should be.
Maybe the first browser to do so, but my colleagues at university were doing this 2-3 years ago (hot profile guided optimized replacement in LLVM for generic/non-browser specific code). I will see if their papers are available without journal access.
I was reminded of the old story about a search engine that tried to supplant JS with a Java bytecode-clone because at the time it was widely believed Javascript had reached its evolutionary limit. How times change!