24.0b1 available, plus gdb7 patch 2

At long last 24.0 beta 1 is available (downloads, release notes). Some technical notes: we now also have new build instructions, and you must use the patchlevel 2 TenFourFox debugger to deal with a problem with debugging symbols. You can get that from the Downloads tab as well. I am hoping that our Tenfourbird friend in the Land of the Rising Sun will be able to make the jump to 24 with us.

So, after months and months and months and months of work (that's almost seven months of work, for those keeping score at home), we are now on PPCBC, the PowerPC-specialized form of BaselineCompiler, and our hardworking methodjit is now released to that great tracing monkey in the sky (though a large part of it lives on in the regular expression library, and some portions are still used by Ion). Was it worth it?

Let's talk about JIT theory. In general, the lower the latency of a just-in-time compiler, the quicker it generates code, but the poorer the quality of the code it generates (no time for significant analysis or optimization). Our first JavaScript JIT, TraceMonkey, was a tracing compiler that had low to medium latency but therefore had low to medium code quality (and because it was a tracing compiler instead of a method compiler, had a tendency to balloon memory usage and get snared compiling code it shouldn't have; much logic was dedicated by Mozilla to avoiding this sort of unnecessary work). Methodjit was a medium-latency compiler. Implemented as JaegerMonkey, it generated code of therefore medium and acceptable quality, but it had a startup penalty which some users complained about during the transition to 10.0. Type inference "JM+TI" improved the code quality, but required even more latency because the interpreter had to run a certain amount of time to generate type information before JM+TI could spit out code optimized to those types (but once it did, the code it generated was pretty efficient, moving the compiler to medium-high latency, but also medium-high quality).

IonMonkey, which we don't yet implement, is a high-latency compiler emitting very optimized code. But its latency comes at a price, particularly on single processors where compilation cannot occur in the background. In fact, Mozilla does not even try to invoke IonMonkey until a particular block of code has run at least 10,000 iterations; it doesn't pay off.

BaselineCompiler (I'll discuss PPCBC in a moment), on the other hand, is a low latency compiler, even lower than TraceMonkey. The browser will attempt to compile code running with as few as 10 iterations (!) in Baseline because there is little penalty to doing so: even though it generates low-quality code, the code that it does generate is over four times faster than the interpreter, and because it generates it so quickly the browser can start executing this code nearly immediately. However, it generates code that is about 60% slower than TraceMonkey, and about 7 times slower than JM+TI.

Because BaselineCompiler cannot make assumptions about the code it runs (methodjit could, because type inference greatly improved its ability to predict at the cost of -- you guessed it -- more latency), it has a dependence on guards to ensure that code that violates its assumptions is properly handled. These guards are an integral part of the inline caches it generates, which are little blobs of code popped out for specific operations as they are run by the JavaScript engine. PowerPC does not do well with branchy code, especially the G5, and because all of our supported CPUs are superscalar we can optimize these commonly emitted type guards with better instruction-level parallelism to reduce branches and improve throughput. That's what PPCBC does, converting these and certain other portions of the inline cache code to PowerPC-optimal straight line sequences, improving our performance on benchmarks by about 15-20% without any penalty to latency. This pulls us to around 40% slower than TraceMonkey, and about 5 times slower than JM+TI.

So by now you should have guessed the tradeoffs, but let's be explicit: virtually all benchmarks suffer. These are long-running sections of code that JM+TI optimized very well, since it had the time to do so. V8 drops on the quad G5 from 2300 to about 450 (but the interpreter clocks in at barely 100). SunSpider time increases by a similar proportion. Because such a large portion of Peacekeeper is predicated on our JavaScript performance, we suffer badly there too. BaselineCompiler also does not utilize the FPU very well, which is really painful on PowerPC because we have no direct ways of converting integer to floating point; benchmarks requiring lots of floating point computation really take it in the shorts, and there is no good way to fix this.

Fortunately, most pages do not have long-running scripts; they have quick-hit scripts, and most of them are using integer or object-based code. This is where PPCBC shines. Pages become significantly more responsive and because we jump into compiled code with a very short delay, there is much less wait. Many, though by no means most, sites fall into this category. YouTube is a site that could go either way, but eBay does very nicely. Gmail feels about the same, but at least it does not regress.

The definitive solution is to implement IonMonkey fully, of course. When fully operational, then after a period of time running, PPCBC-generated code will have accumulated enough type information to allow IonMonkey to emit very nicely optimized sequences, better than JM+TI would have generated for the same input. The good news is that implementing PPCBC first gets us about 2/3rds of the way to Ion since they use most of the same underlying machinery, and it is a predictably performing compiler which is important for our low end systems. (By the way, do not try to enable Ion in the browser. It will crash. You may need to restart it in safe mode to turn this off, so please don't. If you are using the js shell, be sure to start it with the --no-ion option.)

TenFourFox 24 does have better graphics support and improved DOM performance which helps to offset some of this performance loss. We are also using different widget code required by the Australis upgrade, which is improving some of our chrome drawing speed (more about Australis in a moment). I did attempt a build with jemalloc in it, the higher performance allocator that Firefox preferentially uses and that we did attempt an unsuccessful test build with back for the 22.1 release. We scotched it back then for being unable to deal with a memory leak, and jemalloc makes 24 even worse: overnight it ballooned to almost a gigabyte of memory on my quad G5. In addition, the performance delta between regular and jemalloc is much smaller for 24 due to improvements in the core and it only makes a small difference on a subset of sites. So it's not worth the headache now.

The only outstanding bug of significance so far in 24 is a problem with Personas covering up the "traffic light" buttons on redraw (issue 247). It's cosmetic; they repaint when you hover them, and they work normally, so it's just an ugliness that needs to be polished up. This will be fixed for the final release and does not occur with the regular chrome. YMMV, do report as you find them.

Localizers should consider strings frozen for this release, so language packs for 24 can now be created. I am thinking we will have one more beta (24.0.1) to coincide with 17.0.10, and then 24 will replace everything for 24.0.2; langpacks should be ready to go by then. I'll let Chris Trusch comment on the feasibility of that timeframe. Our long-suffering and greatly valued volunteer translators should look for activity in issue 42.

Looking ahead to the future, I am not likely to land Ion on 24 if we can get at least Fx26 running. The reason is simply because I don't know how our systems will deal with it; it's a heavyweight compiler, and it may be too much to be efficient on a G3. We might even only ship it for 7450 and G5, and let G3 and 7400 use Baseline only, which may perform more smoothly on those significantly older machines. However, because PPCBC works fine, Ion is now officially a "solveable" problem given enough time. Evaluating its responsiveness will thus be a big part of the upcoming new unstable branch releases.

What isn't necessarily a solved issue, though, is Australis, the new interface. Some of this code is already in 24, invisibly, and we use some of it for Personas (so fixing the Personas bug is important not because it's cosmetically wacky, but because it's a useful test of code to be used more heavily in a future browser version). However, it still has lots of performance regressions and bugs and it's not even a part of Nightly Firefox builds, just the UX branch; it is now debatable it even makes Firefox 27. Whenever it lands, we need to get Australis working to advance, since almost all of the browser chrome will depend on it; the odds are good as long as 10.6 support doesn't get dropped given our success thus far, but by no means guaranteed.

Anyway, I am relieved that 24 is not an utter disaster. Let me know what you think. I will start working on 26 beta in the very near future as well to kick off our assault on the next ESR, the far-away ESR 31.