4 ms·
Right, but JITs only have the runtime information after a slower warmup period, and even then recording and exploiting this information has a cost too. The real
by ridiculous_fish 12y ago
Right, but JITs only have the runtime information after a slower warmup period, and even then recording and exploiting this information has a cost too. The real divide here is between client/server: fancy JIT techniques can benefit long-running apps on beefy servers, but won't help a Java app launch faster on a smartphone.
- vardump 12y agoThere'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.
- ridiculous_fish 12y agoMaybe - 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!")
- vardump 12y agoAOT 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.