4 ms·
Congratulations on the landing. I've been looking forward to this. Great to see LLVM getting improved to be a better JIT target, too. On point 3, above.. I'v
by kannanvijayan 12y ago
Congratulations on the landing. I've been looking forward to this. Great to see LLVM getting improved to be a better JIT target, too.
On point 3, above.. I've slowly come to the opinion that caching optimized jitcode code is a bad idea in the general case.
Optimized jitcode attaches many constraints across various heap objects (e.g. hidden types), and those constraints would need to be serialized in a way that they can be loaded in a foreign runtime, matched up back to objects in the foreign heap (if those objects even exist). It's pretty complex to build a design that allows you to answer the questions:
1. what piece of JS code in my heap does this cached jitcode correspond to?
2. how do I wire the jitcode into this brand new object graph and attach all the corresponding constraints correctly?
And once you do build that design, the wins would be meager in general. The high-optimization-tier already only runs on very-very-hot code, so it's invoked on only a small fraction of the functions on the heap. Reading the jitcode from disk is slow, and you wouldn't just be reading the code, but the serialized metadata describing how to map that jitcode to the correct set of objects and hidden types that constraints need to be attached to. It's not even clear that the savings on compilation would exceed the costs of reading all this information from disk. Unless you are pulling in, in one go, a large amount of compiled jitcode that you know will be executed.. disk caching has drawbacks that are hard to justify.
The reason asm.js code is a good candidate for targeted caching is because it avoids all of this business. You bake in no heap pointers, and you have no invalidation constraints hanging off of arbitrary heap objects pointing back at your jitcode. Asm is structured so that answering those two questions above is very easy, and it also allows you to cache large amounts of jitcode (a full module) that can then be loaded in one go and be guaranteed to be valid and executable.
Anyway, just food for thought. That said, awesome work and congrats again :)