Showstopper alert: the end of tracejit

We're tracking Mozilla's determination to disable the tracing JIT for JavaScript (bug 693815), which would count as a serious blow to us and would stop us updating to a later version if we weren't able to get the method JIT operational. JavaScript compilation is our biggest marquee feature and we absolutely have to have it functional. This bug has already landed for 10, but the switch-off itself is relatively trivial to back out. What won't be trivial is what will follow, because it will almost certainly break the tracer even if it is reenabled.

Methodjit, which is the JavaScript method compiler, is about 60% written, but this is just a first draft; it is in no way tested to even build, let alone function. It may force switching to a newer compiler at a minimum, though Tobias has already done this work and we are already on a different linker. However, what I'm more concerned about is that I won't have it either stable enough or fast enough by the time it will be our only choice as a compiler, causing regressions at best and wholesale loss of functionality at worst. Those of you who are longtime loyal users already know it took us until almost 7.0 to get most of the bugs worked out of our current tracer, and that was handed to us almost finished and already in use by Adobe (by the way, Adobe has accepted our finalized tracer into nanojit). This is being developed from scratch, is a much larger undertaking and is being forced to occur in significantly less time.

Job one and the best case is that we get the method compiler backend (this includes the assembler and the modifications to the method compiler for the PowerPC ABI) in time for 10 beta; I just don't see this happening in time for 9 and 10 is still iffy.

If we don't get this ready for 10 beta, the current outlook (which can still change, because 10 is the nightly) is that all that will land in 10 is disabling the tracer and investigating any regressions. This is pretty straightforward to undo, but it serves as a warning. Once it is accepted that the tracer will be disabled by Mozilla, then backlogged incompatible changes will start landing, and I hope they land in 11; if they don't, then we will either back them out or force a downgrade to a known working version, most likely the release from 9. We can only maintain this hybrid for so long, obviously, before it becomes incompatible with the JS API the browser requires. If we can't reasonably complete the methodjit and we fall behind, then we will drop to feature parity and source parity will end. Optimally we would like to conclude source parity on a release that coincides with a Long Term Support branch because we will then have the advantage of Mozilla security updates, but we can provide these ourselves if we don't get that fortunate.

If you know someone experienced with PowerPC assembly who would like to contribute, please advise. I'm pretty good with PPC machine code, but I'm no genius, Surely someone from Armonk reads this blog and has some copious free time?

Meanwhile, we are continuing on for 8. For final I have approved Tobias' improvement to the UTF8 to Unicode AltiVec converter that is noticeably faster, and because this is a frequently utilized function that everything calls, everything speeds up. For 9 we will add accelerating colour management and additional encoding methods with AltiVec. Even if JavaScript stalls, the rest of the browser core is advancing at a rapid pace. I expect Mozilla will declare the RC within one to two weeks, and you will get it shortly afterwards.

The QuickTime Enabler unfortunately will not be so timely. Mozilla's Add-On SDK group has stalled on 1.2, which is the SDK required for 8, so I have not been able to do more work on it. I do have some surprises in store and I hope to have this available very shortly when the Mozilla Add-On Builder supports the 1.2 SDK. And I thought that Jetpack add-ons were supposed to be insulated for this ... We'd have done better with a standard XUL extension! We may do this anyway when time comes to integrate QTE directly in to the browser, but we're not up to that point yet.

More soon.