Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox’s new streaming and tiering compiler

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#91

Post by bad_user »

pjmlp wrote: post #32
MaxBarraclough wrote: post #21

A two-tier JIT. Interesting to see tiered JIT compilation catch on the way it has. I seem to remember a few years ago reading that the Java HotSpot team had given up on tiered JIT compilation as being not worthwhile. How far we've come. A whirlwind tour of todays JITs (apologies for the million links): .Net Core seems not to use tiered compilation. It never interprets the IR; everything is run through the same JIT co…

.NET focus always was native code, either AOT with NGEN or JIT on load. The only variants of .NET with interpreter support were from 3rd party implementations, and the .NET Micro Framework, used in NETduino. And now their focus seems to be to improve their AOT story. Another interesting evolution was Android, with Dalvik and its basic JIT, ART with AOT on installation, to ART reboot with an interpreter in Assembly, f…

On .NET Core's focus, that's not actually true:

http://mattwarren.org/2017/12/15/How-does-.NET-JIT-a-method-...

Android optimizes for battery life, but it's also worth noting that Dalvik was a really rudimentary JIT, having no benefits from JIT compilation, only drawbacks, the ART with AOT being a good upgrade.

But tiered compilation is in a different league, being about speculating what's going to happen depending on what the process has witnessed thus far. The point of tiered compilation is to profile/guard stuff at runtime and recompile pieces of code based on changing conditions, which is how you can optimize virtual call sites or other dynamic pieces, which you can't do ahead of time because the missing part is the decompiler which can revert optimizations based on invalidated conditions.

It's really interesting actually, because you can profile a C++ app and use that to optimize your AOT compilation, but the compiler is still limited by the things it can prove ahead of time, or otherwise it would be memory unsafe.

Re: Firefox’s new streaming and tiering compiler

#93

Post by Zpalmtree »

icebraining wrote: post #86
hateduser2 wrote: post #84

Earlier quoted context omitted.

Why can’t you just cache it with a hash?

How would the client know the hash is valid?

Perhaps he means you compile the code locally, hash it, and then next time you can fetch the compiled code from a server, and check the hash matches?

Re: Firefox’s new streaming and tiering compiler

#94

Post by pjmlp »

bad_user wrote: post #91
pjmlp wrote: post #32

Earlier quoted context omitted.

.NET focus always was native code, either AOT with NGEN or JIT on load. The only variants of .NET with interpreter support were from 3rd party implementations, and the .NET Micro Framework, used in NETduino. And now their focus seems to be to improve their AOT story. Another interesting evolution was Android, with Dalvik and its basic JIT, ART with AOT on installation, to ART reboot with an interpreter in Assembly, f…

On .NET Core's focus, that's not actually true: http://mattwarren.org/2017/12/15/How-does-.NET-JIT-a-method-... Android optimizes for battery life, but it's also worth noting that Dalvik was a really rudimentary JIT, having no benefits from JIT compilation, only drawbacks, the ART with AOT being a good upgrade. But tiered compilation is in a different league, being about speculating what's going to happen depending o…

I wrote "And now their focus seems to be to improve their AOT story.", I didn't say anything about .NET Core.

Should have been more explicit, as I was referring to CoreRT and .NET Native.

> But tiered compilation is in a different league, being about speculating what's going to happen depending on what the process has witnessed thus far.

Just as ART was refactored on Android 7 and 8. ART with pure AOT is only for Android 5 and 6.

https://source.android.com/devices/tech/dalvik/jit-compiler

Re: Firefox’s new streaming and tiering compiler

#95

Post by dfox »

pjmlp wrote: post #79
filereaper wrote: post #72

Earlier quoted context omitted.

I'm not sure that JVM allows for streaming code, its centred around class-loading and classes in general. Shipping in fragments of code will require quite an overhaul of that entire architecture. Lambdas and other constructs were added much later via JSR-292 and invokedynamic, streaming stuff in will require quite a bit of shoehorning.

That is implementation specific and not defined as part of the JVM specification. I don't know all the JVM implementations out there, but it wouldn't surprise me if there was one with it implemented. By the way, RMI and Jini worked by streaming code across the network.

Streaming in this case means that you can start generating (or even executing) code before you have complete input. There are some mostly ignorable reasons (having to do with bytecode verification) why you should not stream-JIT Java bytecode. On the other hand in the whole ecosystem you will not gain anything wothwhile given the fact that you need the JVM state to be essentially complete before you start executing anything and on slightly lower-level the .class file format is designed to be compact and not meaningfully streamable.

Re: Firefox’s new streaming and tiering compiler

#96

Post by jnordwick »

icebraining wrote: post #89
jnordwick wrote: post #44

I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference? Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.

Why Hotspot? There are many bytecode languages, with their own execution environments - .NET/CLR, Parrot, BEAM, etc. wasm is an attempt to design one specifically for the web, rather than trying to shoehorn one made for a different environment.

HotSpots optimization and code generation is far superior than any other VM.

But that is kind of my point - there are advanced vms out there. I don't see why the web needs its own vm apart from them. All the differences I see are fairly minimal.

Re: Firefox’s new streaming and tiering compiler

#97

Post by kowdermeister »

flavio81 wrote: post #51
sjrd wrote: post #5

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s.

Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die.

That's the reason we have so many Electron based apps, because it makes UI building really simple.

Re: Firefox’s new streaming and tiering compiler

#98

Post by jnordwick »

dfox wrote: post #95
pjmlp wrote: post #79

Earlier quoted context omitted.

That is implementation specific and not defined as part of the JVM specification. I don't know all the JVM implementations out there, but it wouldn't surprise me if there was one with it implemented. By the way, RMI and Jini worked by streaming code across the network.

Streaming in this case means that you can start generating (or even executing) code before you have complete input. There are some mostly ignorable reasons (having to do with bytecode verification) why you should not stream-JIT Java bytecode. On the other hand in the whole ecosystem you will not gain anything wothwhile given the fact that you need the JVM state to be essentially complete before you start executing an…

Hotspot and wasm are both stack languages. All the other differences seem to be rather small (you could change or ditch the security model fairly easily), and wasm needs some bytecode verification too.

Re: Firefox’s new streaming and tiering compiler

#99

Post by rictic »

dfox wrote: post #85
avaer wrote: post #68

Earlier quoted context omitted.

I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.

Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.

For an example of this model today, take a look at the wonderful A-Frame library for doing 3D scenes, including web VR.

Re: Firefox’s new streaming and tiering compiler

#100

Post by breatheoften »

Does wasm do runtime code specialization? I wonder if there will end up being a way to do to timing attacks against the optimizing wasm compiler/linker step ... Is it possible to setup code such that the optimization time depends on the runtime inferred type of an 'x' that you aren't supposed to have access to ...?
Post reply on HN