3 ms·
> Profile-driven compilation implies that we might invoke an optimizing > compiler while the function is running and we may want to transfer the > funct
by hosay123 12y ago
> 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!
- Someone 12y agoAnd 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?
- sanxiyn 12y agoOne 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.
- wolf550e 12y agohttp://blog.regehr.org/archives/1138 http://blog.regehr.org/archives/1138
- InclinedPlane 12y agoIndeed. 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.
- rayiner 12y agoYou 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=IrByU5HxKYmjyATRj4HIAg&url=http://www.sable.mcgill.ca/publications/techreports/2012-1/lameed-12-osr-TR.pdf&cd=1&ved=0CCcQFjAA&usg=AFQjCNEPX4mWcsIiKztcd7SsLfHS8UtXJg&sig2=JBsd14i3hsnNAJBoqCIkjg https://www.google.com/url?sa=t&source=web&rct=j&ei=IrByU5Hx....
- plantain 12y agoMaybe 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.
- SSLy 12y agoCan you provide papers' names for those of us who have access to academia stuff?