Wednesday, October 19, 2011

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.


  1. Is there a publicly accessible repository for the 10.4Fx changesets, so that we can see what parts of the methodjit need work?

  2. Not yet, but I'm happy to share. Email me.

  3. I am french and I use TenFourFox. I am extremely grateful for the work you do.

  4. this new release is probably the snappiest version yet on my old PowerBook G4. thank you for all the great work. the one issue I've noticed, however, is that I appear to no longer have any control over NoScript. I have plugins enabled, and NoScript is listed as running, but there's no evidence of it at the bottom right corner of the browser window like there used to be.

    just letting you know.

  5. > methodjit, which might never work on PPC

  6. I appreciate all the work you do on TenFourFox - Beta 8 is looking fantastic. I understand you've had to make some tradeoffs. I haven't had much luck with QT Enabler - have you looked at integrating something like VLC Web Plugin to provide more playback options for media?

    I can't say I understand all the challenges you are up against - I haven't done any assembly coding since college. But if I could donate or help in anyway, I'd love to!

  7. VLC Web Plugin is, unfortunately, configured as a plugin.

    However, there is some new integration that will appear in the next QTE. I'm waiting on Mozilla to finally sign off on the 8 RC (hopefully today), and then there will be TenFourFox 8 RCs and the new QTE alpha.

  8. I've noticed an annoying bug in the current 8.0b1. (G5, Leopard)

    Tabs occasionally get corrupted. This also happened in earlier versions (as far back as 5.0), but the new "annoying" thing is that clicking on inactive tabs then acts like a click-lock and mouse movement drags the tab to open in a new window. You can't cancel the drag.


    The first tab is active, even though it appears that the second one is active. Clicking on the other tabs will make them drag.

  9. Well, tab dragging is going away in 8 (final decision), so hopefully bugs like that will be worked out when it reappears (9 or 10).

  10. I like the direction of this product and the performance improvements are exceptional. However, the flaw in the development is to exclude legacy plugin compatibility. This glaring omission makes the browser practically useless for previewing content on the web. The Flash content will be with us for some time going forward and the thought of using multiple browsers to view specific types of content is impractical to say the least. With this type of utility the browser effort will likely fade into obscurity under its own hand. That is a shame because the premise for development and support of the product initially was sound.


Due to an increased frequency of spam, comments are now subject to moderation.