[llvm-dev] WebKit B3 (was LLVM Weekly - #110, Feb 8th 2016)

[Andrew Trick via llvm-dev]

> On Feb 16, 2016, at 8:28 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 16 Feb 2016, at 15:47, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> Can you say anything about the reasoning for having both?  Do you see warmish code that the splat compiler is worthwhile?  I'm used to interpreters and splat compilers being positioned as an either-or choice.  When do you decide to promote something to the splat compiler, but not the "tier 3” compiler?

I’m not a WebKit developer either, but I think David’s explanation is right on the mark. A JVM would not typically bother with both.
-Andy

> I’m not a WebKit developer (though I do use JSC as a case study in the course that I teach), so this may be wide of the mark, but it’s worth noting that the requirements of JavaScript in a web browser are quite different from those of most languages.  A *lot* of JavaScript code has execution time completely dominated by the time spent in the DOM and users notice if memory consumption for this code is high, but don’t notice if the JavaScript execution is slow (even a naïve AST interpreter will find performance massively dominated by the code in the DOM).  Additionally, a lot is executed only once (JavaScript is purely imperative and so ends up with a lot of code that is declarative in Java / C#, for example creating classes and attaching methods to them, is imperative code in JavaScript and is executed precisely once).  Much of this code must be executed in the few tens of milliseconds that exist between the user clicking on a link and the user complaining that the browser is slow.
> 
> The baseline JIT is around an order of magnitude faster than the interpreter[1], but consumes memory for the generated code and does not give a user-noticeable speedup for code that is executed only once.  The baseline JIT and the interpreter both use the same stack layout (this was one of the motivations for replacing the old C++ interpreter with one written in JSC’s custom macro assembly), so it’s comparatively cheap to move from the interpreter to the baseline JIT.
> 
> Finally, WebKit / JSC runs on a lot of mobile devices (iPhones up to MacBooks Pro) where power consumption is a vital design consideration.  It is very important in these situations not to speculatively burn cycles optimising code where the user won’t notice the difference, because they will notice if their battery doesn’t last as long.
> 
> These constraints don’t exist in server workloads and are even quite rare on the desktop.  Few people care if their desktop app takes a couple of seconds to start (and, if they do, they won’t mind if the second time it starts a lot faster because it has cached the generated code).  If a web page takes a couple of seconds to load, then a lot of people will close the tab before it finishes.
> 
> David
> 
> [1] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
>