3 ms·
> To provide more consistent performance, i.e. less slowdown in the worst case? AFAICT, this is the reason for the decline of trace-based JIT compilers. When M
by tarmit 9y ago
> To provide more consistent performance, i.e. less slowdown in the worst case?
AFAICT, this is the reason for the decline of trace-based JIT compilers. When Mozilla introduced JaegerMonkey, their first method-based JIT (which went on to make TraceMonkey obsolete), their reasoning was "tracing tends to interact poorly with certain styles of code" - specifically "the downside of the tracing JIT is that we have to switch back and forth between the [slow] interpreter and the machine code [...] a lot" [https://hacks.mozilla.org/2010/03/improving-javascript-performance-with-jagermonkey/ https://hacks.mozilla.org/2010/03/improving-javascript-perfo...].
For an example of a situation in which tracing performs poorly, consider a hot trace through an if-else statement. The trace will only contain one of the statement's two branches - leading to reduced performance if the "off-trace" branch is frequently taken.
> Faster in the best/average case?
The issue with tracing isn't best-case performance - again, from Mozilla: "when we’re able to “stay on trace” TraceMonkey wins against every other engine" [ibid]. Also, it seems tracing can compete in the average case against somewhat-advanced method-based JITs: "type inference was added to JaegerMonkey, which made it faster on average" [https://blog.mozilla.org/nnethercote/2011/11/23/memshrink-progress-report-week-23/ https://blog.mozilla.org/nnethercote/2011/11/23/memshrink-pr...].
> Less complex to develop and maintain?
In fact, I believe a good method-based JIT is probably more complex than a trace-based one. When compiling at method-granularity, with incomplete information about types, complex features are required e.g. On-Stack Replacement (if the current method becomes "hot", it needs to be replaced by a compiled version), Inline Caches, Hidden Classes and Deoptimization.
In a trace-based JIT, all these features can be replaced by "just compile another trace".
- tarmit 9y ago> Does tracing have any advantages? In summary, I think the advantage of tracing is its ability to give very good best- and average-case performance (albeit with poor worst-case performance), with less complexity than method-based compilation. This is a good trade-off for LuaJIT (a few people supporting ~50kLoC and specifically targeting a small footprint), but not for the leading JavaScript engines (who can afford large teams and millions of LoC).
- bjourne 9y ago> In fact, I believe a good method-based JIT is probably more complex than a trace-based one. When compiling at method-granularity, with incomplete information about types, complex features are required e.g. On-Stack Replacement (if the current method becomes "hot", it needs to be replaced by a compiled version), Inline Caches, Hidden Classes and Deoptimization. Don't you have exactly the same problems in a tracing jit? For example, if the running while-loop becomes hot it would need to be replaced with an optimized version of it.