Hacker News Reader

Comment by hosay123 | Hacker News Reader

    > Profile-driven compilation implies that we might invoke an optimizing
    > compiler while the function is running and we may want to transfer the
    > function’s execution into optimized code in the middle of a loop; to our
    > knowledge the FTL is the first compiler to do on-stack-replacement for
    > hot-loop transfer into LLVM-compiled code.

Reading this practically made my hair stand on end, it is one hell of a technical feat, considering especially they had no ability to pre-plan so that both LLVM and their previous engine would maintain identical stack layouts in their designs. It's really insane they got this to work at all.

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!

View on HN

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

Also http://llvm.org/docs/StackMaps.html

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.

http://blog.regehr.org/archives/1138

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.

Can you provide papers' names for those of us who have access to academia stuff?

Reply on news.ycombinator.com