Speculation in JavaScriptCore

https://webkit.org/blog/10308/speculation-in-javascriptcore/

by pizlonator • 6 years ago

138 67 6 years ago

om24• 6 years ago

If you were ever curious how modern JavaScript VMs (or VMs for other dynamic languages) achieve high performance, this is an awesome resource. It explains tiers, the goals and design of different tiers, on stack replacement, profiling, speculation and more!

JavaScript engines are the most advanced at this (only LuaJIT is even comparable), it would be awesome if Python, Perl, Ruby, PHP or the like aimed for the same level of performance tech.

1337shadow2• 6 years ago

Actually that's available for the Python language as well with PyPy.

pizlonator13• 6 years ago

The post gives PyPy a shout out. But it’s subtle. PyPy is similar but not the same. I think that JSC’s exact technique could be tried for Python and I don’t believe it has.

goatlover• 6 years ago

There is also Julia, which JITs very performant code.

slaymaker1907• 6 years ago

I think that Julia uses the LLVM JIT. When I used it last, Julia was somewhat prone to long startup delays since it would fully compile functions on first execution.

That can work great for long running applications such as its main niche of scientific computing but would be terrible for JS since you want the page to be interactive ASAP.

This is why talking about JIT performance is so complicated. Not only do you need to worry about compilation speed and speed of the generated code, you also have to worry about a lot about impact on memory and impact on concurrently running code. Plus most JITs also need to have some sort of profiling system running all the time as part of those constraints to only spend compilation resources on hot paths.

tyingq6• 6 years ago

PHP has a JIT coming in 8.0, using the same underlying tech that LuaJit does. Unfortunately, most of what people do with PHP isn't CPU bound, so it doesn't help much.

pizlonator13• 6 years ago

And let’s not forget HHVM. That was (is?) quite the beast.

pastrami_panda• 6 years ago

most of what people do with PHP isn't CPU bound

... cause it's I/O bound? Just curious.

tambourine_man2• 6 years ago

This could be a chicken and egg thing. As soon as JavaScript started to get faster, we started using it for more CPU intensive tasks, which in turn led to more investment in optimizations, and so on, in a virtuous circle.

jashmatthews6• 6 years ago

LuaJIT 2.x only uses Dynasm to generate the bytecode VM and not for actual JIT compilation. Runtime JIT is done differently.

Dynasm is actually written in Lua. There's a good guide by Peter Crawley on how to run it here: https://corsix.github.io/dynasm-doc/tutorial.html#compiling

monocasa7• 6 years ago

I'd say that the JVMs (particularly Azul's) are more advanced at this. Even with types, they sill speculate in order to inline across virtual method calls.

But agreed that the amount of perf JS engines can achieve is truly impressive.

pizlonator13• 6 years ago

JSC speculates in order to inline across virtual method calls while also inferring types.

Also inlining across virtual method calls is just old hat. See the post’s related work section to learn some of the history. Most of the post is about techniques that are more involved that inlining and devirtualization.

titzer4• 6 years ago

Many, if not most, of the people working on advanced JavaScript VMs come from a Java background. I would say JS VMs are orders of magnitude more sophisticated in the type of behavioral profiling they do in order to recover types, understand object shapes, and shortcut prototype lookups. While HotSpot and Azul (a progeny of HotSpot) are highly tuned, a lot more investment has gone into bread-and-butter JIT and GC work, whereas JS runtimes have to have a very advanced object model and type profiling infrastructure.

jashmatthews6• 6 years ago

LuaJIT isn't really comparable. Filip touched on why the tracing compilers struggle: tail duplication. Avoiding tail duplication means having heuristics which keep traces short which means limiting your optimization scope.

You can see an example of working around the limited optimization scope by templating Lua here: https://github.com/LuaJIT/LuaJIT-test-cleanup/blob/master/be...

This makes some variables which would otherwise have to be loaded at the start of the trace into constants in the recorded trace. A more complex compiler can just do the same optimizations without the fuckaround.

om24• 6 years ago

Maybe not in architecture and thus in perf ceiling, but they actually get good perf, which is generally not the case for the main implementations of other popular scripting languages IMO. Thanks for highlighting the tracing JIT issue.

anonymoushn• 6 years ago

Is that really the point of that code? It seems like the point is to generate code to map real numbers from math.random to letters in a probability distribution in the smallest number of branches.

hugomg2• 6 years ago

I always love reading more about JavaScriptCore internals although I have to confess that much of the time one of the main lessons I get from it is that life would be much easier if we had types and didn't need to speculate so much in the first place.

pizlonator13• 6 years ago

Not having types is a virtue for the web, where interfaces can change in weird ways. Dynamism leads the engine and the JS code to be less tightly coupled. So, there’s more wiggle room for evolution in the engine and more wiggle room for portability defenses in JS.

So, it just depends on how important the benefits of dynamic types are versus the benefits of static types. I don’t think static types of dynamic types are better; they are just good at different things.

jolux• 6 years ago

There are still ways to program to unstable interfaces in static languages though, and they tend to be safer overall because they are isolated from the rest of the language.

hugomg2• 6 years ago

It wouldn't be the JS we know and love if it had been burdened with a type system designed by a committee sometime in the 90s. That said, one thing we can say for sure is that the dynamic typing doesn't make your job any easier :)

cztomsik2• 6 years ago

How about optional typing, even in some limited form (primitive types, primitive-only structs) with gradually adding more over the time?

I think there was some proposal already but it's probably dead now because I haven't heard about it for a while.

screwreg• 6 years ago

I'd love to see a post like this on instruction selection.

cztomsik2• 6 years ago

Wow, much longer/complete than I would expect, thank you!

Speculation in JavaScriptCore

Related Stories