9.0b1 available

9b1 is available, corresponding roughly to Firefox 9 beta 4. This was a rather troublesome port -- Mozilla did some large internal changes in this release to facilitate type inference (which we do not yet support, stay tuned) and the architectural requirements needed caused significant delay in simply getting the browser to build. Even after that, in DEBUG mode it worked reasonably well but with VMX/AltiVec code paths enabled it crashed incessantly and I had to disable two of our text converters. I'm hoping we can get them reenabled for either 9 final or 10.

It also seems, based on comments in the previous blog entry, that there are still some sites with ridiculously large or complex numbers of scripts that still cause us to run out of stack. For 9, I've made a bandaid and backed the stack pointer all the way up to 0xf0000000 in memory, for a total of 1GB of stack. (On systems less than 1GB of RAM, it doesn't use this automatically, but it potentially could. In this case, it will get swapped to disk, so your system may thrash like crazy but it won't crash; the stack will then shrink back down after execution completes. For this reason, 1GB is now the recommended minimum, though we will still support 512MB machines.) Even with this "bandaid," this obviously doesn't mean we won't overrun it again in the future, and I'm unable to think of any way I can wring more stack out of the browser in 32-bit mode and 64-bit mode is not an option for any architecture except G5.

Methodjit will change this, but I have no idea if it will change it for the better or not. The key issue is that because of our very large register set and our requirement to abide by the OS X PowerPC ABI, we must save large stack frames to the stack, and our stack cannot dynamically grow unlimited. (This is a good thing -- such sites could destabilize the entire computer rather than just the browser if they were allowed to allocate stack forever.) Methodjit as currently written limits us to a much smaller register set, currently 16 GPRs and 8 FPRs of which all the FPRs and around half of the GPRs must be saved on the stack (plus the usual OS X ABI linkage area overhead). This is a smaller stack frame than tracejit uses, which can potentially use all nearly all the GPRs at once, but it may not save us because it may be easier for methodjit-generated functions to recurse with less checking (and that smaller set of registers in use may have performance impact, but I talked about this with Mozilla and it does not appear likely to change -- methodjit is limited to a total of 32 registers altogether). We are exploring ways to propagate an imminent stack exhaustion state to the browser so that a window like the "Unresponsive script" dialogue can be generated rather than, you know, crashing. If you have some ideas about that, see issue 114.

9 is the first installment of what will become methodjit, if we can get it done. This includes Ben's hard work on the macro assembler plus my additional hacking on YARR JIT to enable us to compile regular expressions, which was a gap we suffered from before. With regular expression compilation, the quad G5 running at full tilt drops its SunSpider numbers from around 1600ms to about 1050ms in 9. Yes, this is slightly slower than 8+YARR, probably due to some additional overhead in the interpreter, but it is still significantly faster than 8 alone. (As a side effect, methodjit compilation is enabled, but it does not work. If you were naughty and turned on any of the methodjit preferences in about:config, turn them off before upgrading to 9.0 or you will crash!) On sites like Twitter, it makes a big difference, and it will also accelerate certain extensions like Ghostery and AdBlock Plus. Think of it as a down payment on more JavaScript wizardry to come.

Even though we had to back out some of the AltiVec text conversion code, 9 also includes Tobias' AltiVec qcms colour management code and the completion of the AltiVec scale and colour conversion code, which improves WebM performance quite a bit. It also corrects a regression with JPEG decoding that Chris found and that Mozilla caused -- now JPEG AltiVec decoding is really really fast, and G3 is much faster than it was in 8.0.

9.0 makes a few small subtle interface changes to things like the go/reload/stop button, for really no good reason, but whatever. There are also additional HTML5 and CSS features, font stretching, and improved AJAX performance with a revamped, "chunked" XHR system.

So let's gaze into the crystal ball for a moment and consider some possibilities. Firefox 10 will be the last version of Firefox to have tracejit; it's gone in 11. Preferentially we will have our implementation of methodjit available for 10 beta and we must have it for 11, or we'll have to keep dragging a tracejit-able JavaScript to future versions, which seriously hurts our portability. We could really only fire a "gun" like that once, maybe twice, before changes in the JS API and other internal limitations make it impossible to merge an old JS into a later browser. The long and short is that we really need to have methodjit if we want to continue with source parity. If not, then we drop to feature parity and go from there.

This gets a little more interesting (and exhausting) in that Mozilla is now talking about dropping support for 10.5 in Firefox 13, which was inevitable. It's probably worth reviewing when Mozilla dropped 10.3 for Fx3 and then, of course, when they infamously dropped 10.4 for Fx4 which is why we exist in the first place. Like I say, it was inevitable for Leopard support to have its number come up so quickly; there are few reasons for Intel users to stay on it (Snow Leopard is faster and leaner and still runs PPC software), and Tiger was a much longer lived version of Mac OS X than Leopard was. It is also worth noting who drives each proposal to end support (hint: same person each time). Just sayin'.

The reason this interests us is that while there were many things in 10.5 that we could emulate in 10.4, there are many things in 10.6 (and, for that matter, 10.7) that we can't. Things like, for example, Grand Central Dispatch, or other hidden UI interfaces, or the graphics stack. Right now we simulate the dependency on CoreUI by using the old chrome code, CoreText with Harfbuzz and NSTrackingArea with cleverer management of events (and there are some 3rd party versions of it we could use if we had to), and 10.5 is limited to software rendering also, which makes things easier for us because we are also limited to software rendering and Mozilla has to support that. But it will be much harder when 10.5 compatibility goes away, because Mozilla will make assumptions about the capabilities of the class of remaining machines which many Power Macs will not meet, and will almost certainly try to leverage some of the new features available now that they don't need to worry about legacy support.

But wait, the plot thickens with a partridge and chickens. Most of us have already said our piece on rapid release (and there is some evidence that it is hurting Mozilla's market share already) and more reasonable elements within the Foundation have determined that having a long-term support branch might be worth it (the so-called Extended Support Release, or ESR). The ESR would be the second-tier release and users would be discouraged from running it, but it would be available for corporate or managed environments where rapid-release makes regular Firefox burdensome to manage. 3.6 is sort of filling that role now, so this would finally end updates to 3.6 and replace it with another long-lived branch, and then periodically update it according to a regular, slower timeframe. This idea is not new; the original ESR plan called to start around Fx8, and now it's talking 10, and in all likelihood I don't see much traction on it until the Fx12 or 13 timeframe.

Wait, did you say Fx13? The ESR is an important release for us: it guarantees the ground doesn't shift under our feet more than necessary and we get a certain degree of security patches. While Mozilla will discourage the ESR for regular users, there is nothing that says we can't build on it, and the ESR will be supported for at least 6 months, probably longer. So here's how the scenarios will play out. If we can hang on and make the jump until Fx13 (assuming that is the ESR basis), then we will be on a stable platform with security updates that we can continue to build on. If we develop past the ESR, and we are unable to maintain it, we could be marooned on a Firefox branch that has no updates (and has the requisite bugs from that release to boot). Nothing says that past the 10.5 cutoff date that we will still be able to keep the browser afloat.

So the current plan is to do whatever it takes to get us to the ESR and then start making official releases based on that, while continuing to generate beta releases in parallel off mozilla-beta as we have been doing. If it looks like we'll make it to the ESR after that, then we keep going. If not, we fall back on the ESR, no harm done, and backport features to that as feature parity. When the ESR ends, we enter security parity. That's still a lot of life left, and did you notice that TenFourFox has already had its one year anniversary? Break out the champagne and cheese, man!

As usual the beta will break the QuickTime Enabler because the Add-On SDK team doesn't have the foresight to get a working SDK to coincide with it in the Add-On Builder. Because of the tardiness of this release, the QTE will simply be a maintenance update, and I will post it when it is available.

Release notes and architectures:

• G3
• G4/7400
• G4/7450
• G5