4 ms·
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
by hamburglar 7y ago
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.
- rovr138 7y agoKind of like memchached, https://en.wikipedia.org/wiki/Memcached https://en.wikipedia.org/wiki/Memcached
- pizlonator 7y agoIt’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.
- saagarjha 7y ago> including watchpointing them I assume this isn't literally using hardware watchpoints?
- pizlonator 7y agoYeah
- fulafel 7y agoHeap layout changes between runs due to OS obfuscation (ASLR).
- pizlonator 7y agoI 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.
- blinkingled 7y agoIBM 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/ https://www.eclipse.org/openj9/docs/aot/