7.0b1 available, whither 6.0.2, and a special pirate edition: YARR, THIS INTERPRETER SUX

So, it's Labor Day weekend and I've spent it watching Law and Order DVDs, painting the house trim and tweaking TenFourFox. Today, for those of you with nothing better to do on a holiday weekend either, 7.0 beta 1 is available, roughly corresponding to Firefox 7 beta 4. Generally I am loathe to talk about subjective speed improvements in this blog because they are just that, subjective. However, there is a lot to like about Fx7, and the biggest one isn't the memory footprint improvements (because we're forced to take a hit on that, read on). Instead, it's the graphics stack, and the new Cairo really benefits our rendering pipelines. Pages paint quicker, animations are snappier and movie playback is less jerky. The improvement is subtle, and there is still much improvement to come, but I think virtually everyone will notice the difference. Tobias, the early trailblazer on 7, said it was the first version he felt was truly useable on his PowerBook. While I politely demur that I've been perfectly happy with TenFourFox on my iBook G4 ;) , I certainly do agree that 7 is better in nearly every metric.

Also new in 7 is the beginnings of a new HTML5 canvas backend (Azure, which will eventually take over the entire rendering pipeline; fortunately for us, the CoreGraphics version is likely to work and even if it doesn't there's still Cairo), improvements to Sync, a new Telemetry module for reporting performance back to Mozilla (we don't track this information ourselves, but if you want to remind Mozilla that PowerPC lives, go for it :), a new API for sites to determine load times and adjust themselves to slower systems, and CSS3 ellipsis support.

Oh, and it takes http:// out of the menu bar. Strangely, I'm not as offended by this as I thought I would be, but I'm not wild about it. gopher:// does still appear, though, and so does https://, so I guess that's all that matters. :D

So, yeah, about that "memory footprint" thing. Firefox 7 is being touted as the first product of Mozilla's MemShrink project, bragging numbers that reduce its overall memory usage by 20-50%, will leak considerably less, and will more aggressively release memory as tabs are closed. Naturally such must be taken with a grain of salt, but I will say that memory usage is noticibly less on both my G5 and my iBook. In typical usage on the iBook, comparing 6 versus 7, 7 seems to use about 25% less memory, and the system is able to reclaim it more easily.

Our problem, however, is it appears we are dramatically underestimating the PowerPC's JavaScript stack demands. Longtime TenFourFox veterans will recall several bugs that in succeeding order jack up the stack ceiling more and more, and in this version we jump from 64MB of stack to 256MB of stack (repairing issue 85). This is unfortunately unavoidable because the PowerPC ABI requires us to save registers to the stack on function calls and the PPC has a massive number of registers. As OS X has a hard cap limit we must ask for this cap in advance, and the original limits we asked for were too small because our stack frames are so much larger, causing it to crash out on certain scripts. This means in the worst case the browser may require a minimum of 256MB of RAM just for the stack, let alone the app or the rest of the OS. For this reason, starting with 7.0, the minimum system requirements will be for 512MB of physical memory. Systems with 256MB of RAM will no longer be supported. Every Power Mac we support in TenFourFox is capable of at least that much; even my Outrigger beige Power Mac 7300 has a gig, and my blueberry iBook G3 has 576MB. The recommended minimum will now move to 768MB. Fortunately, thanks to the other improvements, you'll be able to do more with the rest of your memory, and the 256MB is only a peak possibility, not a persistent requirement. So do yourself and your Mac a favour (RAM is dirt cheap these days) and max out your memory now.

A few of you will be wondering about that cryptic title, and that's the other thing that we need to mention: YARR sucks. Mozilla is expanding their JIT to JavaScript regular expressions using WebKit's YARR library. YARR originally used the Perl-Compatible Regular Expression library (or at least their heavily hacked version of it) as the interpreter fallback for when a JIT was not available, and since we don't (yet) have support for methodjit or the Nitro assembler on PowerPC, we used PCRE for regexp evaluation. In 7.0 Mozilla "upgraded" YARR to a version that now uses its own interpreter as the fallback instead of PCRE. All of their shipping platforms use the JIT, which to be sure, is very quick.

We knew about this going in and several of Tobias' patches were to fix the JavaScript core to deal with the situation where the YARR JIT was not enabled. When I got this together and ran it through Dromaeo for conformance testing, however, I was shocked to see the G5 drop from 110+ runs/sec (in 6) to a dismal 65. All of this regression was paid on the regular expression part of the benchmark. When I hacked PCRE back into the JSRegExp portion of the library, the number went back to the old figure. While WebKit admits benignly that YARR's interpreter is "slower" than PCRE, frankly we really take it in the shorts with YARR and so will any other tier-3 platform that doesn't yet have methodjit/macro assembler support. I filed this with Mozilla as bug 684559 so they can ignore it, but we are shipping with PCRE back because we can't afford a hit like that. Eventually we will have methodjit and we can play in the full JIT party too, but that won't be for a couple cycles yet.

Specific to us, because of my continuing downtime (AT&T is coming out to look at installing a second NID this week for my T1), there has not been any new TenFourFox-specific features in 7 other than updating Sluggo for the new Apple CEO. However, as mentioned, issue 85 is repaired, and a 10.5 specific bug with dropdowns (issue 72) has a putative fix. This fix is limited to 10.5; if you are one of those affected by that bug, please let me know if triggering dropdowns actually crashes the browser instead, because this would imply that my theory is incorrect (i.e., that issue 9 should only be worked around on 10.4). 10.4 is not affected by this issue. This version does not fix issue 84, the table spacing issue; although we have test cases, we haven't narrowed it down to the exact Mozilla patch that provoked the issue and I don't want to wreck my one working 6 repo until I don't need it anymore since none of my ad-hoc offline repos have history. As this bug is a simple nuisance, occurs only on certain sites and the sites in question are otherwise useable, we're shipping with this bug for now.

Soon we will need to turn our efforts to methodjit so that we can keep pace with Mozilla's improvements to JavaScript. If you know PowerPC assembly language and want to help, we can always use more coders.

I'm also working on a new release of the TenFourFox QuickTime Enabler. Watch for it in the coming week or two.

In news from the Mountain View mothership, Mozilla is planning a chemspill for their chemspill, viz., a Firefox 6.0.2. This version "fixes the fix" for DigiNotar, which seems to have caused some collateral damage, but their fix-fix is similarly controversial. I am not planning to generate a 6.0.2 as 6.0.1 will fail safe and I'm not convinced there won't be more changes in the pipeline before 7 emerges. If you are affected by the changes in 6.0.1, you could always use this beta, of course. :) However, if there is a large demand for it, I will consider releasing it as well.

For now, read the 7.0 beta release notes, and grab for your architecture:

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