Created attachment 8888286 [details] [diff] [review] Hackish prototype Scripts are currently Ion-compiled when their use count reaches ~1000. Ion does pretty aggressive inlining of scripts, this is necessary for really hot code (like the first 5 Octane tests). On workloads like Speedometer, this inlining is not helping as much and compilation time is an issue. I'm attaching a hackish prototype to use the optimization level infrastructure Hannes added (I had to fix some regressions and bugs but it mostly worked). With this patch we have 2 Ion tiers: we still compile scripts with use count 1000 but we only inline 1-2 levels deep and don't inline large functions. We also include use count checks and when a script's use count reaches 100,000 we recompile and use the heuristics we have now. It works surprisingly well. Octane is mostly unaffected or becomes a bit faster, Sunspider and Kraken regress by a few %, and Speedometer wins at least a few points on my machine (not sure how much because it's pretty noisy). I'm not sure if this is worth pursuing now as this stuff is hard to get right and I think there's lower-hanging fruit still.
Similar to bug 1080776?
(In reply to Guilherme Lima from comment #1) > Similar to bug 1080776? It's similar but a bit different: the approach there is to add a tier between Baseline and current Ion (at warmup count 100) whereas the patch here "delays" full-Ion. In general I don't think Ion-compiling with warmup count 100 (that bug) is a good idea.
Comment on attachment 8888286 [details] [diff] [review] Hackish prototype Review of attachment 8888286 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jit/IonBuilder.cpp @@ +5421,4 @@ > MRecompileCheck* check = > MRecompileCheck::New(alloc(), target->nonLazyScript(), > optimizationInfo().inliningRecompileThreshold(), > + MRecompileCheck::RecompileCheckType::Inlining); The problem is that the more we inline the more we would be likely to invalidate the compilation because of inlining issues. I suggest we use a larger threshold factor than 4, or with an exponentiation by the inlining depth, such that we do not invalidate the code too frequently.
When Apple added their LLVM-tier JIT, they found that the performance improvements from a 4th tier mostly came from better inlining information. Although this design would be valuable by itself, it would be even better to have tier-4 Ion able to read type information from tier-3 Ion's ICs.