Friday, May 31, 2013

Adios, Camino

The venerable alternative-Gecko browser Camino has officially breathed its last. As a Camino user back before it was called Camino, I would still be using Camino today if Mozilla hadn't announced they were ending not only support for PowerPC in Fx4, but also ending support for true embedding in Gecko, which is what Camino relies upon. Truly, as most of us here know, the browser had been on life support for nearly a year. I didn't seriously think they'd make the jump to WebKit; they would be just another WebKit shell and there are tonnes of those.

If Camino had continued past Mozilla 1.9.2, there's the chance that TenFourFox might have been a continuation of Camino, not a continuation of Firefox (TenFourCam?). But even though it was rough going with this port initially, I think the right decision was made because by going with Firefox as the basis we can keep better technological pace with the Web as much as possible. Nevertheless, I will miss Camino terribly, and while Mozilla may have had good reasons for making those technical decisions, it still sucks.

UPDATE: Samuel Sidler, one of the Camino developers, has a small epitaph for Camino on his blog.

Monday, May 27, 2013

IonMonkey PowerPC phase 2 complete

We've moved from phase 1 (putative construction) to phase 2 (successful compilation and linking). It makes a big mess and immediately segfaults, but at least it builds. A portion of mild concern was that AsmJS requires an exception handler (!), so I'm hoping it can still be properly disabled in 24 (#undef JS_ASMJS) or we could have some difficult to debug problems with asm.js scripts. For the remainder of 22 I'll be filling in more gaps, but I won't be able to do much more testing until 24-aurora.

Saturday, May 25, 2013

Google Code twists the knife

As if we didn't have enough good reasons to switch to SourceForge (previously), Google gives us another one: new projects can no longer offer direct downloads, and existing projects will no longer be able to make new downloads after January 2014.

Again, Google doesn't owe us anything and we don't pay them anything, but this makes their open source hosting less than useless; this is a family blog, or I could sum up my response in two words. Well, actually, I can sum it up in two letters, and one of them is a U.

Monday, May 20, 2013

You can do what you wanna do / in ICC version 4 living colour management profiles

The 22 port is complete. If people want changesets, I can offer an early set; I'm now working in an optimized G5 build, and the browser seems to work fine.

The biggest change in this release is dropping Growl support for Mozilla XUL notifications. They work very well in 10.4, and web pages can (with your permission) trigger them too. Please note that my plan was always to support XUL notifications when they came along; they're much more flexible and integrated than Growl notifications. Image decoding has also been tuned to reduce memory overhead in this release, and image decoding can occur on multiple threads for people on multiprocessor G4 and G5 systems.

A user issue report is the impetus for issue 225, in which we will change the browser to accept ICC v4 profiles by default for colour management (not all v4 features are supported, but the profiles will at least work instead of falling back to sRGB which is usually amazingly wrong). If you are on 21, you can try this now by changing gfx.color_management.enablev4 to true and restarting the browser. Test before and after with this colour management test page. I would particularly like to make sure this works fine for 10.5. 17 users, you can try this too, but there is a bug with colour management on greyscale images such as xkcd, so you may wish to disable it after you've finished playing with it a bit; this fix will be added to 17.0.7. I plan to make this pref switch for 22.0 and 17.0.7 assuming there are no objections.

Some good news for a change. Most of the JavaScript test failures are actually attributable to the test harness -- if I run it in segments instead of "great big fricking ball of tests," it completes them as well as it has been previously completing them, at least. I suspect Python is doing something wrong here or maybe I'm just overloading the G5, since the test system will now cheerfully peg all your cores at 100% CPU if you let it. There is one new test failure which is indeed in asm.js and that is because -- surprise surprise -- it assumes a little-endian architecture. Not much we can do about that right now. Overall, however, 22 does apparently suffice as a worst-case drop-parity branch, much to my relief, and right away I'm going to start logging security fixes that need to land on it just in case that eventuality occurs.

Saturday, May 18, 2013

The sputtering last stand of methodjit

I finished the port of 22 early so that I could enjoy my vacation in June in peace, at least theoretically, and this post is being made in the debug build. (Shout out to vasi: your download progress indicator patch only needed minimal changes for 10.4. I just had to add a stub for NSRectFromCGRect and it seems to work fine.)

OdinMonkey (a la asm.js) landed in 22, Mozilla's hyperoptimizeable subset of JavaScript which appears to have a critical reliance on IonMonkey; the JavaScript test suite can't even complete now without the Python test harness going crazy on those particular tests along with all the other accumulated intentional failures. The loss of regression testing, even though the browser appears to still basically work, should be considered an extremely crippling limitation; in the worst case scenario where we don't make it to 24, I think it might be better to make the more robust 21 the point of dropping to feature parity since I still have a test suite that at least completes in that version. More testing is needed, but in any case, I don't see any reasonable way that gluing together methodjit is sustainable now and 22 will be its last stand. For 24, the only way out is through.

Jan de Mooij at Mozilla did get back to me with what needs to happen for the Baseline compiler, which as previously mentioned is the low-profile version of Ion, and that will be critical for 24 (issue 224). Baseline is a lot simpler to implement, but it does a lot less, of course. The good news is that about 2/3rds of what it requires I'd already done for Ion, leaving only some assorted leftover pieces that I need to write (I also have to get it to at least link completely, what I'm calling "Ion stage 2"; even though not everything needs to be implemented, the stubs need to be present). However, looking at how the compiler works, I'm gloomily predicting benchmark losses of around 25-30% slower. It's still faster than TraceMonkey was, but it's going to be slower than 17. I can't do much in the 22 timeframe other than get it to build completely because Baseline wasn't enabled until 23, so no testing will be possible this cycle.

In that sense, it's probably a good thing that people are only just now noticing that I dropped plugins completely in 19 (yes, it's true, for those new to this blog), so some may stick with 17 for a little longer for the plugins and as a fringe benefit will still have methodjit at near its operational peak. While I'd like to eventually get Ion up on 24 stable, it's going to be entirely dependent on how much backporting I have to do. Such is the nature of life in twilight.

Wednesday, May 15, 2013

Mozilla shoots us in the stomach

Bang (previously, previously).

So I'm pretty displeased about this, and once the SPARC and MIPS consumers find out that their respective JavaScript methodjit compiler ports no longer work either, they, too, will be displeased. And SeaMonkeyPPC guys, methodjit was sure nice while it lasted, yes? (You'll lose it in the equivalent for Firefox 23.) But if we were beloved by Mountain View, we wouldn't be a tier-3 port, would we?

However, since I'm a physician by training and medical metaphors simply flow from my fingertips, severe traumatic stomach wounds can be survived with surgery. (See how well I pulled that together? My kid sister is a trauma surgeon. You should only panic if I say that Mozilla shot us in the head.) And I'm trying to operate on this patient as quickly as I can between, you know, having an actual day job in a nearly totally dissimilar field.

Some of the JavaScript team at Mozilla are suggesting that we try implementing the Baseline compiler first, which seems a little strange, since Baseline came on board after Ion. The way it's supposed to work is that Baseline builds a really simple unoptimized code stream -- no type inference or other kinds of "expensive" optimization -- and after a certain number of runs, then big bad Ion comes on and emits superior code, and that runs instead. In fairness, this seems to work as a one-two punch better than methodjit, so I'm not unhappy about the end result, just the fact that Mozilla has really boxed me in here. Implementing Baseline first does have the advantage that there is some common code, I can pull Ion up in stages, and it would be better than the interpreter (but that's like saying rotten fish for dinner is better than nothing for dinner). And Baseline is easier on the processor to compile code, similar to the way TraceMonkey worked, so really slow systems like our G3 users will notice that latency is less even if the code is not as well optimized. But our benchmarks may take it on the chin, and like Mozilla would agree, I don't like shipping regressions.

I'm still waiting for my JS contacts to explain in more detail what's needed to bring Baseline up. The problem is that there's no fully functional Baseline in 22, and there is no point in building 23 -- we want 24 because we want to move to the next ESR at (almost) any cost. So I'm going to hold our stable users on 17 as long as possible. 22 is going to come out, the last version where methodjit was relatively unmolested, and I will start on that port this weekend now that beta 1 is available so I can still take some time off (which I will spend dreaming of throwing darts at Mozilla's corporate office). That, and putative 17.0.7, will still come out on time as usual.

Currently Ion is to the point where it builds, but does not link -- I'm still missing some stuff which I am implementing piece by piece (not yet to phase 2). When 24 hits Aurora, then I'm going to try to get Baseline running first assuming Mozilla isn't blowing smoke up my tailpipe and run numbers. I figure with the work I've already done, getting Baseline to pass tests is going to be at least a full cycle, so there will be no Aurora for you to play with unless there is a major breakthrough (putative 17.0.8 will be released, though, and if there is a major security issue I will put out a bridge 22 release). If I'm lucky, there will be a 24 beta for you in the beta timeframe prior to 24.0 final. Play with it, see if the expected regression is still worth shipping, and Chris T and our localizers can start work with that. If people judge it acceptable, we issue 24.0 on the unstable branch and 17.0.9 on the stable branch to have one more shakedown for bugs, and move stable branch over with 24.0.1/17.0.10, and 17 support ends (I hope Tenfourbird is able to jump to 24 with us -- I would love to see that project continue). If the benchmark regression is not acceptable, we'll just have to hope there's enough time left on 17 to get Ion ready.

This sucks.

Friday, May 10, 2013

17.0.6 available

17.0.6 is available, word to your moms' on Sunday, on the Downloads tab (release notes). This also includes the issue 217 fix that appeared in 21.0 on Wednesday. Assuming no problems, this will be final on Monday.

Wednesday, May 8, 2013

21.0 released

First, let me issue a capsule music review by saying that The Beach Boys' Sunflower is their best work since Pet Sounds, and anyone who knows my taste in music knows the high regard in which I hold the latter. Brian Wilson's muse guides me as I write the following. Thus concludes my channelling of Lester Bangs, rest in peace.

21 is released (release notes). This is not really a groundbreaking milestone, but it is a noticeably quicker one; we're finally getting on the other end of the JM+TI curve after we took a bad hit around 19-20. In fact, V8 is about 10% faster on the G5, mostly due to improvements to regular expressions, although I'm still unhappy with V8-Crypto's performance and I'd like to unregress that if we end up stuck on JaegerMonkey. I also got canvas compositing working with the 10.4 CoreGraphics backend, though I really need some reftests to verify if it's actually doing it correctly (but to my eye and some basic examples, it appears to be). 21 also includes a fix for a crash in the CoreGraphics backend (issue 217) which will also be fixed in 17.0.6, due out this weekend.

21 also includes the Firefox Health Report, which because of our branding work comes out as the "TenFourFox Health Report." I'm not sure what to do with this yet. It's disabled because the stuff currently gets sent to Mozilla, not me, and I imagine they don't really care. The time and performance standards are also based on computers considerably newer than our cheerfully geriatric workstations, so I don't even consider them relevant. I'll probably completely strike it from the UI for 24. Play with it if you like; I don't really see this as worth building infrastructure for, since the necessary knobs to twiddle it are mostly out of my control.

Under the surface, JavaScript is still kind of a mess, even though it works at least right now. We're getting more and more divergent from Mozilla, so we pass tests we shouldn't (mostly due to stack bailouts, which interestingly don't make us crash anymore because we have so much stack and we allow big stack allocations -- people who remember early problems with stack crashes in the TraceMonkey days will probably snicker at this point), and our methodjit is hacked to avoid certain performance regressions introduced during the Ion-Jaeger integration work, which makes us slightly out of step with an obscure feature.

The IonMonkey work still doesn't build yet, though the assembler and the macroassembler do parse; the lowering and move emitter code need to be reworked now that the former two pieces are done using different assumptions, and then stubs need to be written to let it link. At that point it should be able to crash successfully, sigh. Mozilla has not made any promises about keeping JaegerMonkey in 24, and those of you using Firefox on Linux PowerPC may wish to keep an eye on the interpreter changes because it's being drastically simplified (and this is likely to make using the interpreter even less performant, though given that V8 doesn't even have one you should be consider yourselves fortunate there's an interpreter at all). If the worst case happens and Mozilla yanks JM before the 24ESR switchover, I might issue interim 17 and 22 releases until ionjit gets mounted, but I really don't want to be in that position. Alas, Ben's PowerBook is out of commission, so he is unable to contribute. You can help! Voice your love, affection and ability to program in issue 178.

Speaking of 22, I'm not terribly worried about that port, since JM-solo builds were still supported in this release; there might be some build system changes to work around, but the merge work should not be major, he says while rapping his knuckles on a convenient plank of wood. This port will start early because I'm actually due to take a vacation (ha! fat chance) in June for the first time in nearly two years, and I want to make sure the bulk of the porting work is done in advance. But don't worry, the 22 and 17.0.7 builds will still be out on time. Don't worry, baby. Everything will turn out all right. Smile.