A scrollbar too far (or, why Apple can't kill a Snow Leopard)

One of my perpetual sources of anxiety is whether when Mozilla will drop support for 10.6 Snow Leopard. We've done pretty well keeping 10.4 and 10.5 compatible code in our widget library, and it looks like the code landing for Australis (the new "look" for Firefox) will be compatible with only moderate tweaking at most so far. Because Snow Leopard is essentially a tuned 10.5 and has relatively few UI-related changes, our now fairly streamlined widget library code functions quite well, considering, on all three operating systems (essentially forward-porting the 10.4-specific stuff from 3.6 and the 10.5-specific stuff from 16, for those weirdos in the audience running TenFourFox on Rosetta in 10.6). There haven't been substantial changes to our widget patches since 19, and even then only for the compiler update.

But then of course there's 10.7 Lion, Steve Jobs' Operation Market Garden, where scrolling was screwed and Rosetta was removed and Java was jettisoned (wait, that's a good thing) and scrollbars were iOSified and Save As was deprecated and you can't tell if an application has quit or not. And like 10.6 left behind an entire generation of Macs -- every Power Mac ever made -- 10.7 left behind every 32-bit Intel Mac, and 10.8 won't even run on those 64-bit Intel Macs that can't boot a 64-bit kernel, including my 2007 Core 2 Duo Mac mini which I use for taxes and Android stuff. 10.8 does smoothe out some of the rough edges of 10.7 but doubles down on them in other respects, and why bother downupgrading to 10.7 if I can't upgrade to 10.8 as quickly as possible thereafter? I could boot 10.7 on my mini, but then I lose all the features I need from 10.6, I can't upgrade to 10.8, and I have no apps that demand either one. So 10.6 stays.

In that context, then, I suppose it's not surprising that Mozilla (and probably Chrome as well) has a problem: 43% of their users are on 10.6, an OS that Apple is supporting pretty much in name only right now and will almost certainly cease to after 10.9 emerges (expect word on that from the incredibly oversubscribed WWDC). And why is this? Well, look at the other two numbers: while 10.8 is growing, 10.7 is at 30% and dropping. I can't be the only one who made the calculation that it's better to stay on 10.6 if you can't go to 10.8, and there are still lots of 10.6-only machines in use that really aren't that old. Since Apple isn't maintaining Safari anymore for 10.6, it's alternative browsers ahoy.

Unlike previously premature attempts to kill off platform support on Mozilla's part (ahem), there's a big operations problem brewing here. Apple is obsoleting hardware faster and faster, and Mozilla can't buy more 10.6 or 10.7-capable systems because Apple won't make them. (Used hardware is not generally acceptable for the types of testing they need to do; their Mac mini build farms work very hard.) They might be able to build on a later version of OS X (but not for much longer?), but they wouldn't be able to test how well it works on earlier ones. So they're going to repurpose the 10.7 test systems for 10.6, since it continues to be the majority of Firefox's OS X user base, and make 10.6 and 10.8 the major test platforms until Apple finally has a developer beta of 10.9.

All this is good news for us, of course. On the dark day when Mozilla makes 10.7 the supported minimum, all supported Macs will run a 64-bit build, have hardware acceleration, and use the new UI and related libraries -- none of which is true for us (we still use some Carbon code, limiting us to 32-bit even on G5, we don't have hardware acceleration, and our scrollbars are actually visible and scroll in the correct direction). At minimum we would have so many changes to pull forward that we would almost certainly have to split off separate widget and theme subsystems, and merging work would increase significantly if we could get it to function at all. But with almost half their users on 10.6, even considering that the number is slowly dropping, I'm now not anticipating this will occur until at least the next ESR and the chances of a working TenFourFox 31 have just increased big time.

IonMonkey PowerPC phase 1 complete

Tonight after several weeks of feverish work I finished the basis for IonMonkey PowerPC, the next-generation JavaScript JIT we will be implementing, including bridging our previous assembler (and all Ben's hard work on optimizing branches) to IonMonkey and then writing up the new macroassembler. IonMonkey is all stack, all the time, so there are quite a few differences in implementation (though to the Linux readers in the audience, this may make our IonMonkey backend easier to port to Linux PPC than our current JaegerMonkey/methodjit backend because I can no longer make certain assumptions about how the stack is organized). The old macroassembler still remains as an integral part of YARR and is still used to compile regular expressions.

Phase 2 will be getting it to compile, phase 3 will be getting it to do simple operations, and phase 4 will be getting it to pass the JIT test suite (which if it does means there is an excellent chance it will "just work" in the browser). Please note I am still unconvinced about how well it will perform, though the front end for IonMonkey can optimize code a lot better than JaegerMonkey could, and because it does everything on the stack I hope our 1GB allocation is enough because I don't think we can get any more out of it in 32-bit mode.

Mozilla has at least not laughed uproariously and said "no" with a bone-crushing sound to the plea to keep JM+TI (JaegerMonkey + type inference) in ESR24, even if only as a compile-time option. There is no SPARC ionjit (nor does it look like there will be one), nor MIPS, so those architectures will also lose JIT support when JaegerMonkey is removed, and since it appears that JM+TI's continued existence does not immediately impair work on certain pieces of the ionjit baseline compiler there is less push to remove it right away. This was not the case per se with tracejit back in the ESR10 days where tracejit actively impaired work on type inference. I really don't want to have to unload ionjit on the user base right away; I'd rather have lots of cycles to get it right, and keeping 24 on JM+TI means we have one more full stable release lifecycle on a very dependable engine that's bought us a lot of mileage and plenty more time to get Ion to that same level.

FirefoxOS dev phones sell out

By which I mean they're out of phones for sale on the very first day, and I blame you lot for why I can't buy a Peak Developer Edition. The specs are modest, but the price is eminently reasonable. Last night at 10:30pm the store was down for maintenance, I get up at 5:45am today to get one, and bam.

I'm a longtime Android user, driven to the Nexus One when Apple dropped 10.4 support within the iOS 4 timeframe, and while I don't love it I certainly don't hate it. My Galaxy Nexus is a solid device. Still, when I got to play with a Palm pre 2 (thanks, Ed!) for a period of time it was a delightful machine, and I'm hoping FirefoxOS recaptures that ease of development and feeling of openness that webOS had. Bugs are to be expected in early dev releases like this, and a friend of mine who put a nightly on a castoff phone a couple months back reported it didn't even do cut and paste (!), but I expect it has now developed to the point where you can dogfood it and I certainly hope Mozilla is. If FirefoxOS launches well, it would do much to preserve their relevance and a freer alternative mobile platform in a post-PC era.

IBM's getting out of the x86 server business

The Wall Street Journal reports today that IBM is exiting the x86 server business, citing poor margins, and selling it off to Lenovo who previously bought their ThinkPad line when IBM got out of the consumer market.

IBM, like Apple, has never done well in low-margin markets. While they were just as enthusiastic about consumer PC sales during the 1980s and early 1990s, and their ThinkPads were some of the best laptops ever made (even if they did have x86 chips in them), when personal computers became a commodity IBM saw the writing on the wall and got out. Now the same thing is happening with servers: relatively cheap Intel and AMD CPUs running Linux are easy to deploy and easy to purchase, and it's not worth the R&D and deployment costs for the shrinking margins they bring in to keep them in the product mix.

What does this mean for PowerPC? Well, it means IBM will continue to develop and improve the server-grade POWER architecture since it'll be shortly the only architecture (save z/Architecture, though the modern versions of those chips have many underlying similarities to POWER) that they sell. Whether this trickles down to the embedded and game markets is another story; PS4 will be AMD-based and the Xbox 720's Durango CPU will also be x86 and appears to be another AMD design also, leaving the Nintendo Wii U and its Espresso CPU (developed by IBM) as the only PowerPC-based console. It's not at all clear whether IBM's going to do any more development in the gaming space, but Freescale is still chugging out embedded PowerPC CPUs and recently introduced the QorIQ AMP 64-bit e6500 series with clock speeds through 2.5GHz and as many as 12 cores on a 28nm process, the linchpin of Freescale's new base-station-on-a-chip line for mobile broadband.

So I think it's good news for the architecture and brightens the future for POWER because it allows IBM to focus more on the major architecture that has consistently made them money. Confidently look for more PowerPC chips sneaking into more pieces of your daily life, including uppsala, the big POWER6 in my server room that serves you floodgap.com. Say hi!

"Twenty-one. That's blackjack." "Hit me."

Like any idiot who gets a natural 21, I just had to take another hit. 21 was ported relatively uneventfully. Some of the underlying work for Australis, the new Firefox UX, is in this version (invisibly), and they ported pretty much as is to 10.4, so that's a good sign for the future. I'm still watching some of the later workbugs but I don't see them landing until at least Fx24 (Fx23 is the current nightly), and Australis isn't going to be in place in full by then. Other than breaking issue 82 again, which was a printing bug introduced by an incompatible fix way back in 6.0 and is trivial to back out, the browser appears to basically work in debugging mode. getUserMedia still functions fine, we're starting to get into that curve back to where we should be with JavaScript performance, and there continue to be improvements to the graphics stack which make animations and display smoother. Later this week once I've done a couple other bug investigations, I'll flip it over and build optimized for further testing, another version in the can relatively painlessly for a change.

But I just had to, had to, take another hit with the king and the ace showing. The "hit" is something called jemalloc, which is a improved memory allocator with lower overhead: instead of asking for little tiny allocations from the operating system, jemalloc creates "arenas" of larger memory blocks (assuming that more allocation requests are following) and then parcels those out with a faster internal routine. It also scales better between threads by keeping multiple arenas in play so they don't have to contend with each other. Certain kernel-level operations and multithreading are not well optimized on 10.4 as issue 193 demonstrates, and anything that reduces the amount of locking and waiting for kernel resources is clearly a benefit because of Firefox's increasing dependence on threads for multicore systems. You can read about the gory implementation details here.

Firefox works just fine with jemalloc disabled (since it is intended to be mostly transparent), and that is how we've shipped TenFourFox so far. (Near as I can determine, AuroraFox and SeaMonkeyPPC aren't using it either, or it's not actually turned on.) Well, 10.4 must have a really crummy default allocator, because after some fiddling to account for operating system differences, I was able to slot it in and WOW! the browser not only starts up apparently normally, but is noticeably faster. Most of the deadlocked sites we're tracking in issue 193 are up to 25% faster in wall clock time compared to the non-jemalloc 21, which is already itself faster than 20. Sites with less contention are less improved, of course, but it's an improvement right where we need it. Even if it doesn't fix the actual underlying issue in the kernel, it eliminates another source of contention, and that's enough to get us through the hump. 10.5 is considerably less affected due to kernel improvements, but it could still benefit as well.

But, and here's the "busted" part, major parts of the browser's interface to OS X are screwed up when using jemalloc as the allocator. While menus, widgets and gadgets all work, cut and paste doesn't work, minimizing the window doesn't work, and drag and drop doesn't work (they don't do anything other than log an error to the system console). If I rebuild the browser with jemalloc statically disabled, they start working again, so that's the problem. That's not shippable no matter how much faster the browser is, and there is at least one crash bug related to drag and drop on Intel 10.5 that caused Mozilla to disable jemalloc on anything less than 64-bit 10.6. The PowerPC kernel might not use the same code or crash in the same way, but right now I can't even test it.

I'm suspicious that memory alignment is the problem and it's stomping on some sort of internal memory move routine, but it's going to take a while to debug it and IonMonkey is still highest priority, so this is going to slip to Job 2. Still, look for it soon once I get IonMonkey into a working state (the interested can watch issue 218). 21 is an improvement over 20, but if I can get jemalloc off the ground, maybe we'll be able to say blackjack with 22 or 24. Never bet against the house!

20.0.1: A Firefox Chemspill Odyssey We're Not Releasing

As strains of Strauss play and HAL murders spacemen and men dressed as apes fling bones that turn into spaceships in geosynchronous orbit, Mozilla is chemspilling 20.0.1 for two Windows-specific bugs that do not appear to be issues for us. Therefore, we will not open the pod bay doors release a 20.0.1. If you know differently, please advise. Mind the explosive bolts.

Meanwhile, the port of 21 has begun, and I'm about 50% done with the IonMonkey macroassembler. More about this later.

And pay no attention to that big black monolith. It's just a Macintosh TV turned upside down and buried.

Blink, there's a new HTML rendering engine

The Web is all abuzz about Blink, Google's fork of WebKit, for use in Chromium and Google Chrome (and, apparently, Opera as well, since it will track Chromium).

I've already said my piece on WebKit, but Blink significantly changes that dynamic. In fact, Blink is likely to completely fragment what would have been a cold WebKit-only future because it is almost certain to evolve and implement new features faster than WebKit will, and exported to everywhere that Google code runs (Android, too). And, well, that's good news in a sense because it avoids one kind of perilous future, but it's bad in another because there won't be much of a brake on Google implementing features in Blink to make Google properties run better or even exclusively in it. Remember, that's the whole reason they made Chrome in the first place, and Microsoft isn't the only one that "embraces and extends."

Maybe it'll be Blink that eats the Web, not WebKit after all.