Now, this is sort of my fault, because this "fix" (I use the term advisedly) was even back in the betas, but I was slack in the non-Dobbs way and only ensuring that the tests succeeded, not what the actual numbers were. However, you can see from AreWeFastYet that in early-mid December (ignore the actual numbers, just look at the trends) the red JM+TI line suddenly worsened (that's us) in SunSpider and V8, and most of the V8 regression seems to have been due to V8-Richards, which took a nose dive around the same time. This isn't of interest to Mozilla, because they built a fast path into IonMonkey (instead of the quick'n'dirty stub for JaegerMonkey) and the combined purple JM+TI+Ion line marches downwards apace since V8 mostly runs in Ion now, and for ports stuck on the interpreter the speed is probably not any more perceptibly glacial than it was before. It's only us weird arch ports like MIPS and SPARC that have only methodjit, and we're the only ones to get screwed. A heads up would have been nice instead of an opaque message about a minor change to the JSAPI in the technical newsgroup.
As far as IonMonkey, I've actually made a bit of progress with it. By basing ourselves on the x86 backend -- which incredibly is cleaner than the perverse little ARM one -- I was able to use hints in their code to hopefully preserve all the hard work Ben did on our assembler, particularly his tinkering with G3/G4 and G5 branching for performance on specific processors. I need to do some work on the existing PowerPC assembler to add some new opcodes and Ion jump handling methods, but this is value-added work that shouldn't affect methodjit and will be silently part of 21. The Ion macro assembler, however, is not much like the methodjit macro assembler and will need to be written from scratch using the template in the x86 version. I'm still rather bearish on Ion because it does a lot of mucking around with stack frames, something PowerPC is not very good at, and it's questionable how much advantage it will take of our register set even though theoretically we can pump all 32 at it (but then we have to save those extra non-volatiles in every function prologue plus any non-volatile floating point registers, and that sucks, so we're not going to do that). I think I have all the pieces in js/src/ion/ppcosx; they just don't work or build, and much of the code isn't written (particularly the higher level abstract stuff which I don't even understand yet). The first order of business is just to get it to compile. Volunteers, as always, solicited. These pieces will be part of the 20 changesets when they become available, but if you want an early peek, just ask.
17.0.5 will fix websites using databases affected by issue 213 and should be out sometime this weekend or late Sunday, so watch for it then. 20 (also with that fix) will probably not be out until next weekend because I'm on a work trip in Sacramento, that wretched hive of scum and villainy known as the state capital, but we'll see if I can get some downtime between meetings. However, I want to do some basic compatibility testing on it prior to release to make sure our reverting the "fix" didn't cause some other unpleasant regression somewhere else, so I'll need to be at my desk first.