{"id":1498,"date":"2011-11-23T15:35:53","date_gmt":"2011-11-23T04:35:53","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1498"},"modified":"2011-11-23T15:35:53","modified_gmt":"2011-11-23T04:35:53","slug":"memshrink-progress-report-week-23","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/11\/23\/memshrink-progress-report-week-23\/","title":{"rendered":"MemShrink progress report, week 23"},"content":{"rendered":"

The only significant MemShrink-related change that landed this week was that David Anderson removed TraceMonkey<\/a>, the tracing JIT compiler.\u00a0 In fact, TraceMonkey was disabled<\/a> a while ago, so the effects on code size and memory consumption of its removal have been felt since then.\u00a0 But it feels more real now that the source code is gone (all 67,000 lines of it!), so I figure it’s worth mentioning.\u00a0 (BTW, many thanks to Ryan VanderMeulen who has been going through Bugzilla, closing many old TraceMonkey-related bugs that are no longer relevant.)<\/p>\n

People have asked why TraceMonkey isn’t needed any more.\u00a0 In my opinion, tracing compilation can be a good strategy for certain kinds of code, such as very tight, non-branchy loops.\u00a0 But it tends to do badly on other kinds of code.\u00a0 Before JaegerMonkey, JS code in Firefox ran in one of two modes: interpreted (super slow), or trace-compiled (usually fast).\u00a0 This kind of bimodal performance is bad, because you lose more when slow than you gain when fast<\/a>.\u00a0 Also, because tracing was the only way to make code fast, huge amounts of effort were put into tracing code that shouldn’t really be traced, which made TraceMonkey really complicated.<\/p>\n

Once JaegerMonkey was added, the performance was still bimodal, but in a better way:\u00a0 method-compiled (fairly fast) or trace-compiled (usually fast).\u00a0 But the heuristics to switch between the two modes were quite hairy.\u00a0 Then type inference was added to JaegerMonkey, which made it faster on average than JaegerMonkey+TraceMonkey.\u00a0 Combine that with the fact that TraceMonkey was actively getting in the way of various additional JaegerMonkey and type inference improvements, and it was clear it was time for TraceMonkey to go.<\/p>\n

It might sound like there’s been a lot of wasted effort with all these different JITs.\u00a0 There’s some truth to that.\u00a0 But JavaScript is a difficult language to compile well, and people have only been writing JITs for it for a few years, which isn’t long when it comes to compilers.\u00a0 Each new JIT has taught the JS team about ideas that do and don’t work, and those lessons have been incorporated into the next, better JIT.\u00a0 That’s why IonMonkey is now being developed — because JaegerMonkey with type inference still has a number of shortcomings that can’t be remedied incrementally.<\/p>\n

In fact, it’s possible that IonMonkey might end up one day with a trace compiler for really hot, tight loops.\u00a0 If it does, this trace compiler would be much simpler than TraceMonkey because it would only target code that trace-compiles easily;\u00a0 trace compilation would be the icing on the cake, not the whole cake.<\/p>\n

Enough about JITs.\u00a0 Time for this week’s MemShrink bug counts.<\/p>\n