The only significant MemShrink-related change that landed this week was that David Anderson removed TraceMonkey, the tracing JIT compiler. In fact, TraceMonkey was disabled a while ago, so the effects on code size and memory consumption of its removal have been felt since then. 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. (BTW, many thanks to Ryan VanderMeulen who has been going through Bugzilla, closing many old TraceMonkey-related bugs that are no longer relevant.)

People have asked why TraceMonkey isn’t needed any more. In my opinion, tracing compilation can be a good strategy for certain kinds of code, such as very tight, non-branchy loops. But it tends to do badly on other kinds of code. Before JaegerMonkey, JS code in Firefox ran in one of two modes: interpreted (super slow), or trace-compiled (usually fast). This kind of bimodal performance is bad, because you lose more when slow than you gain when fast. 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.

Once JaegerMonkey was added, the performance was still bimodal, but in a better way: method-compiled (fairly fast) or trace-compiled (usually fast). But the heuristics to switch between the two modes were quite hairy. Then type inference was added to JaegerMonkey, which made it faster on average than JaegerMonkey+TraceMonkey. 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.

It might sound like there’s been a lot of wasted effort with all these different JITs. There’s some truth to that. 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. 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. 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.

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

Enough about JITs. Time for this week’s MemShrink bug counts.

P1: 31 (-0/+2)

P2: 132 (-3/+8)

P3: 60 (-0/+2)

Unprioritized: 4 (-0/+4)

Not a great deal of movement there. The quietness is at least partly explained by the fact that Thanksgiving is happening in the US this week. Next week will probably be quieter than usual for the same reason.