Hacker News Reader

Comment by pizlonator | Hacker News Reader

That would be great but it’s hard because the trick, at least in JS VMs, is to have the JIT specialize based on the heap.

So you’d need a heap snapshot or some way to link the generated code to a different heap.

Maybe not impossible, just hard enough that it’s not widespread.

View on HN

IIRC V8 can now provide deterministic JIT+heap images in addition to preparsed bytecode images.

EDIT: worth noting that other JS VMs like JSC have these APIs for bytecode too, but i can’t remember off hand whether they can do generated code too.

It does seem like you could do JIT with a persistent cache which stores the JIT output along with a key that's a hash of all the relevant system parameters like CPU model and VM parameters like heap size. This would mean that the typical case of re-running a program in the same environment would be pre-warmed.

Kind of like memchached, https://en.wikipedia.org/wiki/Memcached

It’s much harder than that because the JIT is speculating on what lots of objects in the heap are doing, including watchpointing them to constant fold properties. It’s not clear what the key should be in that case.

Still not impossible but I want to be clear on what exactly makes this hard. CPU model for example is not what makes it hard.

> including watchpointing them

I assume this isn't literally using hardware watchpoints?

Yeah

Heap layout changes between runs due to OS obfuscation (ASLR).

I would bet that a VM isn’t going to be deterministic enough to produce the same heap twice even without aslr. Just building a deterministic JS engine seems like a super hard problem.

IBM OpenJ9 JVM does that with the AOT feature. It's good for startup time and the AOT code can be still further optimized by the JIT. https://www.eclipse.org/openj9/docs/aot/

Reply on news.ycombinator.com