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.