Item — HN Reader

There's absolutely no reason why there needs to be a warm-up period. You can cache the JITted binary code to disk. CPUs really don't care how the code was produced.

A sampling profiler can be pretty cheap. Just record stack state every n milliseconds, no need to instrument everything.

Actual JITting can be done on those other cores that would otherwise be idle anyways.

1 comments

Maybe - it sounds tricky though, since optimizations can be rendered invalid across runs (e.g. a plugin may be loaded that invalidates a monomorphic dispatch optimization). So you must track and re-validate the assumptions underlying the optimized code before it can be used. Also startup code is often executed once, and so is a poor candidate for expensive JIT optimizations. That said, in principle it seems like one could do as you say - it's just hard.

Empirically, the industry seems to be moving from JIT to AOT, at least for clients. .NET -> Ngen, Dalvik -> ART, JavaScript -> asm.js, etc.

(Oh, and it's a suspect assumption that there exists other cores that "would be idle anyways!")

AOT doesn't exclude JIT! Doing both is the winning combination. AOT will ensure fast start-up time and JIT will ensure optimization to runtime conditions.

It's tricky I'm sure, but it'll happen.