Monday, January 30, 2012
10 converted to release
As threatened, all update notifiers have been updated to reflect 10 to give our holdouts a chance to update while they still can. Also, I'd like to welcome Theo to our volunteer technical support squad, who has graciously volunteered to take part on Tenderapp. If you are willing to help enlighten the unenlightened as well (and file a real bug report now and then), send me an E-mail.
Sunday, January 29, 2012
10.0 RC (finally) available
The RC is finally available, after a few late-breaking bugs landed, and the G5 jammed most of the day to poot out these builds. The only difference (other than what Mozilla fixed) between this and the beta is that the help and feedback links now connect to Tenderapp, and some minor internals changes so we don't pick up Firefox hotfixes by accident. Speaking of, Mozilla did adjust garbage collection between beta and RC, and that seems a bit snappier.
I'll post more when Mozilla determines how they will maintain the ESR in their tree (no doubt as another repo). Meanwhile, 11 will be a changeset-only release because it is finally time to decommission the old Apple Network Server and I need the time to do so. Ben's changes to the methodjit branches and David's software G3/G4 square root routine will be in the next stable and unstable betas. Stay tuned.
Release notes and builds:
I'll post more when Mozilla determines how they will maintain the ESR in their tree (no doubt as another repo). Meanwhile, 11 will be a changeset-only release because it is finally time to decommission the old Apple Network Server and I need the time to do so. Ben's changes to the methodjit branches and David's software G3/G4 square root routine will be in the next stable and unstable betas. Stay tuned.
Release notes and builds:
Friday, January 27, 2012
Waiting for RCgodot
Ordinarily there would be RCs by now but Mozilla has not tagged the build branch yet and I know of at least one bug that may land prior to ship. Watch this space over the weekend.
Saturday, January 14, 2012
Tenderapp support now available
As I mentioned in the previous couple of posts, Mozilla will EOL Firefox 3.6 when 10 ESR exits the qualification stage (for the lifecycle of an ESR release, see the Mozilla Wiki proposal). As we are the unofficial overflow for PowerPC and 10.4 users that will be orphaned after 3.6 runs aground, we are likely to pick up a large number of new users in the very near future, and expecting Mozilla to continue to support them through SUMO is not fair on their resources.
Fortunately, Tenderapp offers free accounts to open source projects with an application, and I am pleased to announce that they have accepted ours. Starting today, users will be able to file feedback and questions through our own TenFourFox Support site. The Support link under the Help menu automatically points to this new site, there are Help and Support tabs on the main page and Start page, and the TenFourFox Help option will point to it with 10.0 final.
Please explore it and see what you think. Chris, contact me privately so I can give you a login to allow you to read and reply to support tickets. Other people who are interested in helping with the support effort, please request in the comments.
Fortunately, Tenderapp offers free accounts to open source projects with an application, and I am pleased to announce that they have accepted ours. Starting today, users will be able to file feedback and questions through our own TenFourFox Support site. The Support link under the Help menu automatically points to this new site, there are Help and Support tabs on the main page and Start page, and the TenFourFox Help option will point to it with 10.0 final.
Please explore it and see what you think. Chris, contact me privately so I can give you a login to allow you to read and reply to support tickets. Other people who are interested in helping with the support effort, please request in the comments.
Sunday, January 8, 2012
10.0b1 stable available
Sorry about the RSS blip earlier; that was me hitting the wrong button. After a little more delay than I had previously planned, 10.0 beta is available, the first of our "stable" releases (based on the putative Firefox ESR).
Firefox 10 is actually a really strong release. In addition to the usual gratuitous UI change(s) (this time around it's the disappearing/reappearing forward button if you are using large icons in the toolbar), there are some remarkably solid additions in this release and my personal favourite is the Inspect Element feature. You can right-click on anything and select Inspect Element, and the HTML element appears in context with its children and parents, highlighted for your visual convenience. Even cooler is that you can dynamically alter the style, turn inherited and specified properties on and off, and find it within the page source. This is much like the old and much-beloved DOM Inspector (from Firefox 2.x and previous; still in Classilla and SeaMonkey) except that it is fully integrated within the main browser and not a separate XUL component. Great work, Mozilla!
Fx10 also includes 3D CSS transforms and properties. We render these in software (son of no-OpenGL-2-in-10.4), so performance is not great, but they work and they work surprisingly well, considering. Here is a static example from MDN: notice that all the 3D objects on the page are not images, but have selectable text, because they are in fact just transformed text. The proof of the pudding is in course in the animation, though, so why not a rotating HTML5 logo? Performs pretty well, even in software rendering on the 1GHz iMac G4.
Mozilla is also including a full-screen API where, if you permit it, a web page can dynamically open itself up to full screen. Now, if you're like me, you realize that the possibilities for phishing just jumped about twelve or thirteen times, and using it for full-screen video on pretty much any Power Mac is hopeless (my quad G5 even at full tilt can't push 1920x1080 WebM video in software). But it would be nice for presentations and other kinds of remotely-hosted demonstrations, and an excellent way to fool your boss that you're working (just switch to the tab with a static screenshot of Outlook taking up the whole screen :).
Finally, Mozilla has enough confidence in AMO to make extensions default to compatible. Now your addons don't get nuked every time you upgrade, unless, of course, the server says they are incompatible or they use binary or other unstable APIs. Those of you using the QTE will notice that it didn't get disabled like every other beta did. In fact, I didn't need to update any of my addons when I started using 10.0b1 personally. Nice!
Not all was wine and roses with the port. Besides breaking my keyboard over the weekend (and I really liked that keyboard, because it works well with all of my USB Macs even in OS 9), Mozilla upgraded the WebM libvpx to 0.9.7, wrecking our custom AltiVec work. This is not all bad because 0.9.7 is multithreaded and we support that on multiprocessor Macs, so this should help performance on marginal G4s with dual CPUs, and I was able to reconstruct most of our code in the end. Report irregularities.
Continuing in the bad news-good news department, tracejit is still in 10 but we can't ship it as default: SunSpider limps to a similar speed, but Dromaeo is 15-20% slower. I can't find a specific cause for this, and frankly if I try undoing things I'm likely to break JM+TI and JM+TI is the future. So the future is now. I am sufficiently confident in the performance and stability of JM+TI for it to now be the default. If you are using JM+TM, consider disabling tracejit entirely and turning on type inference before upgrading to 10 beta. I will leave tracejit in this release and the rest of the 10.0.x stable branch releases for those people who are absolutely convinced that methodjit is wrecking their machine somehow (it's not), but you need to be aware of the performance differential relative to 9, and it will not be in 11. We landed some microoptimizations and fixes in 10, but they are relatively minor and there is not much change in the numbers. However, Ben has some ideas on how to rework branches to more effectively make use of branch prediction and not make the backend insanely overcomplicated. We also have a new contributor who is working on a fast software square root for G3 and G4. This work will land on both stable and unstable, so there will be a beta for that particular stable release when it's ready.
Finally, something Mozilla did broke the way double and triple clicks select text. I think I have a workaround for it, but it might behave ever so slightly different from usual. Report non-trivial irregularities in issue 122.
Back in the good news column, Tobias' VMX text converters are patched up and back in with hardened algorithms, plus a new one for XPCOM text conversion, which should significantly restore page processing speed on G4 and G5. This completes most of the targets that support SIMD in Mozilla Core except for an obscure one that only deals with plugins, though we are always looking for others. None of these regress the infamous issue 84 and so I think we can call this a win. I also put in a minor fix to the backing JavaScript so that about:memory isn't a mess of unresolvable Unicode line drawing symbols.
It still isn't clear how Mozilla will handle the ESR rollout. My bet is that there will be a mozilla-esr repo or some such, from which we will pull for the stable releases. I am exploring low-cost ways of getting us an online helpdesk and support area for users so that we can eliminate our dependency on SUMO. Chris has volunteered to help with support. Other volunteers are requested. The beer offer stands.
For 11, we, and by "we" I mean "me," really need a break and this is the best one (closest to 10, so likely to have no major issues) to sit out on. I will still do a changeset for debug builds, but it's going to literally be just a placeholder, and there will be no binaries. If others want to take this one for the gap, go for it. Part of what I need the time for is to migrate www.floodgap.com off the 14-year-old Apple Network Server 500 that it still runs on to the big IBM POWER6 dual-core server sitting around idle except for being the gopher server and handling Veronica-2. There should be no service downtime like our unpleasant two months "network free" this summer because I'm simply going to transparently move the IP address to the new machine. I also really need to do finishing work on Classilla 9.3.0 and TTYtter 2.0 while I still have a chance. The next scheduled unstable branch release per se will be 12. I'm still planning to do it based on mozilla-beta if for no other reason than avoiding the small amount of perpetual churn on -aurora.
In the meantime, release notes and architecture builds:
Firefox 10 is actually a really strong release. In addition to the usual gratuitous UI change(s) (this time around it's the disappearing/reappearing forward button if you are using large icons in the toolbar), there are some remarkably solid additions in this release and my personal favourite is the Inspect Element feature. You can right-click on anything and select Inspect Element, and the HTML element appears in context with its children and parents, highlighted for your visual convenience. Even cooler is that you can dynamically alter the style, turn inherited and specified properties on and off, and find it within the page source. This is much like the old and much-beloved DOM Inspector (from Firefox 2.x and previous; still in Classilla and SeaMonkey) except that it is fully integrated within the main browser and not a separate XUL component. Great work, Mozilla!
Fx10 also includes 3D CSS transforms and properties. We render these in software (son of no-OpenGL-2-in-10.4), so performance is not great, but they work and they work surprisingly well, considering. Here is a static example from MDN: notice that all the 3D objects on the page are not images, but have selectable text, because they are in fact just transformed text. The proof of the pudding is in course in the animation, though, so why not a rotating HTML5 logo? Performs pretty well, even in software rendering on the 1GHz iMac G4.
Mozilla is also including a full-screen API where, if you permit it, a web page can dynamically open itself up to full screen. Now, if you're like me, you realize that the possibilities for phishing just jumped about twelve or thirteen times, and using it for full-screen video on pretty much any Power Mac is hopeless (my quad G5 even at full tilt can't push 1920x1080 WebM video in software). But it would be nice for presentations and other kinds of remotely-hosted demonstrations, and an excellent way to fool your boss that you're working (just switch to the tab with a static screenshot of Outlook taking up the whole screen :).
Finally, Mozilla has enough confidence in AMO to make extensions default to compatible. Now your addons don't get nuked every time you upgrade, unless, of course, the server says they are incompatible or they use binary or other unstable APIs. Those of you using the QTE will notice that it didn't get disabled like every other beta did. In fact, I didn't need to update any of my addons when I started using 10.0b1 personally. Nice!
Not all was wine and roses with the port. Besides breaking my keyboard over the weekend (and I really liked that keyboard, because it works well with all of my USB Macs even in OS 9), Mozilla upgraded the WebM libvpx to 0.9.7, wrecking our custom AltiVec work. This is not all bad because 0.9.7 is multithreaded and we support that on multiprocessor Macs, so this should help performance on marginal G4s with dual CPUs, and I was able to reconstruct most of our code in the end. Report irregularities.
Continuing in the bad news-good news department, tracejit is still in 10 but we can't ship it as default: SunSpider limps to a similar speed, but Dromaeo is 15-20% slower. I can't find a specific cause for this, and frankly if I try undoing things I'm likely to break JM+TI and JM+TI is the future. So the future is now. I am sufficiently confident in the performance and stability of JM+TI for it to now be the default. If you are using JM+TM, consider disabling tracejit entirely and turning on type inference before upgrading to 10 beta. I will leave tracejit in this release and the rest of the 10.0.x stable branch releases for those people who are absolutely convinced that methodjit is wrecking their machine somehow (it's not), but you need to be aware of the performance differential relative to 9, and it will not be in 11. We landed some microoptimizations and fixes in 10, but they are relatively minor and there is not much change in the numbers. However, Ben has some ideas on how to rework branches to more effectively make use of branch prediction and not make the backend insanely overcomplicated. We also have a new contributor who is working on a fast software square root for G3 and G4. This work will land on both stable and unstable, so there will be a beta for that particular stable release when it's ready.
Finally, something Mozilla did broke the way double and triple clicks select text. I think I have a workaround for it, but it might behave ever so slightly different from usual. Report non-trivial irregularities in issue 122.
Back in the good news column, Tobias' VMX text converters are patched up and back in with hardened algorithms, plus a new one for XPCOM text conversion, which should significantly restore page processing speed on G4 and G5. This completes most of the targets that support SIMD in Mozilla Core except for an obscure one that only deals with plugins, though we are always looking for others. None of these regress the infamous issue 84 and so I think we can call this a win. I also put in a minor fix to the backing JavaScript so that about:memory isn't a mess of unresolvable Unicode line drawing symbols.
It still isn't clear how Mozilla will handle the ESR rollout. My bet is that there will be a mozilla-esr repo or some such, from which we will pull for the stable releases. I am exploring low-cost ways of getting us an online helpdesk and support area for users so that we can eliminate our dependency on SUMO. Chris has volunteered to help with support. Other volunteers are requested. The beer offer stands.
For 11, we, and by "we" I mean "me," really need a break and this is the best one (closest to 10, so likely to have no major issues) to sit out on. I will still do a changeset for debug builds, but it's going to literally be just a placeholder, and there will be no binaries. If others want to take this one for the gap, go for it. Part of what I need the time for is to migrate www.floodgap.com off the 14-year-old Apple Network Server 500 that it still runs on to the big IBM POWER6 dual-core server sitting around idle except for being the gopher server and handling Veronica-2. There should be no service downtime like our unpleasant two months "network free" this summer because I'm simply going to transparently move the IP address to the new machine. I also really need to do finishing work on Classilla 9.3.0 and TTYtter 2.0 while I still have a chance. The next scheduled unstable branch release per se will be 12. I'm still planning to do it based on mozilla-beta if for no other reason than avoiding the small amount of perpetual churn on -aurora.
In the meantime, release notes and architecture builds:
Wednesday, January 4, 2012
Two forks diverged in a wood, and I, I took the one that had free beer
(* which is odd since I don't drink, but it seemed better)
It's official: Firefox 10 will be the Extended Support Release, basically Mozilla's new legacy release, and will mean the end of Fx3.6 support on April 24, 2012 (assuming current release schedule).
The ESR will mean, finally, a stable base for long term maintenance. This is of great personal relief to yours truly, because keeping up with the Mozilla treadmill ("making the hippo dance") is not a lot of fun sometimes. It is also quite possible that Mozilla will use the ESR to cast off support for OSes they don't want to support anymore (even though more progressive elements are resisting this), and I would not be surprised to see 10.5 users forced onto the ESR along with other undesirables such as Windows XP SP1 and Windows 2000.
Right now the TenFourFox 10 port is mostly done and I have a debug build mounted which appears to basically work. I have not tried getting AltiVec builds up yet; I'm planning to lock myself in my office and do that this weekend when I'm not on call. Other than some annoying trivial internal changes, the biggest reason this port was delayed was that Mozilla changed most of their legacy NSPR booleans (viz., PR_TRUE, PR_FALSE and the PRBool type) to C++ booleans (viz., garden variety true and false). This invalidated around two-thirds of our patch sets and required a lot of manual adjustment. There was also a bug in plain methodjit that this unearthed and yielded several days of fruitless rooting around in the code until I found a working solution earlier today. The tracejit seems to basically work, but I won't be able to fully test it until I get opt builds running, so I have not made a decision about whether people will be forced to use JM+TI in this release (if tracejit has minor problems, I will try to fix them; if it's unacceptably crippled by Mozilla's type inference changes, however, it's probably not worth repairing). I have decided that we will use methodjit for the chrome, because this will cut back on memory and the chrome code is obviously not changing; the tracejit decision relates specifically to Web content.
Once 10 is kicked out to the unwashed masses, development becomes bifurcated. Unlike the regular ESR, which will only get high-level security and stability fixes much as the moribund 3.6 gets now, our stable branch (based on the 10 ESR) will get other fixes and possibly even new minor features. Most users will get this release and receive point updates to it, which should be reassuring to our change-averse general audience. If a major feature needs to be backported, there will be a regular beta-and-RC cycle.
Development of the main Firefox channel will still continue in the background on the unstable branch. Let's make this clear now for you pedants in the audience: the unstable branch is not intended to make release-quality builds, just betas and test builds. There will almost certainly be bugs and minor ones will not be fixed on any particular timetable; the point of the unstable branch is simply to keep the port viable in a general sense (and to give me and the other contributors a well-deserved break). Only beta builds will emerge on the unstable branch, not RCs. I may sit out 11 to give myself a break, and pick up with 12.
The next scheduled ESR will be Firefox 17. I think it's unlikely we get that far, but hey, I said we were dead in Firefox 5 and Tobias got the linker working; I said we were dead by Firefox 11 and Ben showed up with the macroassembler. So don't rely on my picks for the NFL postseason if you want to keep your money. If we make it to Fx16, then Fx16 will get a regular beta-and-RC cycle, and the stable branch will move to 16 and then settle again on 17. It would be a miracle if we made it to Firefox 24, though (it's doubtful Mozilla would still even support 10.6 by then, and we're not going to make a "Lionized" TenFourFox because that would make me nauseous), but we would still do security updates, of course.
There are a few other things I'd like you guys to think about. I have had some internal discussions with Mozilla and TenFourFox is currently their draft recommendation for Power Mac and 10.4 users still on 3.6 (always subject to change, of course, but this seems like their intent). Right now we piggyback on SUMO, Mozilla's support system, but this doesn't seem fair when Mozilla won't support PowerPC at all. Instead, we're going to need to start up our own user support and triage network like I already have set up for Classilla ("Report-A-Bug"), just on a much larger scale. I'm soliciting for someone or a group of someones to head up triaging user reports and helping support the influx of new users we will likely receive, translating user reports into bug reports as appropriate. Please E-mail me or nominate yourself in the comments. You will get free beer if we ever find a bar that would serve our PowerPC-using riffraff kind.
The second thing I'd like people to consider is what to backport in case we don't make it to Firefox 17 (or when we don't make it to Firefox 24), i.e., when we drop to feature parity. We would need to implement important CSS and layout features from later Mozilla releases to keep the browser core reasonably current, possibly new JavaScript features, and definitely some important extension-like functionality to incorporate into the interface and maintain ourselves (the QTE, adblock along the lines of Camino's, user agent switching to mimic later browsers, etc.). This is not a Christmas list and Christmas has already left the building; it is a "need to have or we lose significant functionality" list. I'm not soliciting for this list yet because we're still at source parity for the time being. If it looks like we fall off the wagon, we'll need to powwow.
I'm shooting for 10 beta next week. I'll post if there will be a significant delay.
It's official: Firefox 10 will be the Extended Support Release, basically Mozilla's new legacy release, and will mean the end of Fx3.6 support on April 24, 2012 (assuming current release schedule).
The ESR will mean, finally, a stable base for long term maintenance. This is of great personal relief to yours truly, because keeping up with the Mozilla treadmill ("making the hippo dance") is not a lot of fun sometimes. It is also quite possible that Mozilla will use the ESR to cast off support for OSes they don't want to support anymore (even though more progressive elements are resisting this), and I would not be surprised to see 10.5 users forced onto the ESR along with other undesirables such as Windows XP SP1 and Windows 2000.
Right now the TenFourFox 10 port is mostly done and I have a debug build mounted which appears to basically work. I have not tried getting AltiVec builds up yet; I'm planning to lock myself in my office and do that this weekend when I'm not on call. Other than some annoying trivial internal changes, the biggest reason this port was delayed was that Mozilla changed most of their legacy NSPR booleans (viz., PR_TRUE, PR_FALSE and the PRBool type) to C++ booleans (viz., garden variety true and false). This invalidated around two-thirds of our patch sets and required a lot of manual adjustment. There was also a bug in plain methodjit that this unearthed and yielded several days of fruitless rooting around in the code until I found a working solution earlier today. The tracejit seems to basically work, but I won't be able to fully test it until I get opt builds running, so I have not made a decision about whether people will be forced to use JM+TI in this release (if tracejit has minor problems, I will try to fix them; if it's unacceptably crippled by Mozilla's type inference changes, however, it's probably not worth repairing). I have decided that we will use methodjit for the chrome, because this will cut back on memory and the chrome code is obviously not changing; the tracejit decision relates specifically to Web content.
Once 10 is kicked out to the unwashed masses, development becomes bifurcated. Unlike the regular ESR, which will only get high-level security and stability fixes much as the moribund 3.6 gets now, our stable branch (based on the 10 ESR) will get other fixes and possibly even new minor features. Most users will get this release and receive point updates to it, which should be reassuring to our change-averse general audience. If a major feature needs to be backported, there will be a regular beta-and-RC cycle.
Development of the main Firefox channel will still continue in the background on the unstable branch. Let's make this clear now for you pedants in the audience: the unstable branch is not intended to make release-quality builds, just betas and test builds. There will almost certainly be bugs and minor ones will not be fixed on any particular timetable; the point of the unstable branch is simply to keep the port viable in a general sense (and to give me and the other contributors a well-deserved break). Only beta builds will emerge on the unstable branch, not RCs. I may sit out 11 to give myself a break, and pick up with 12.
The next scheduled ESR will be Firefox 17. I think it's unlikely we get that far, but hey, I said we were dead in Firefox 5 and Tobias got the linker working; I said we were dead by Firefox 11 and Ben showed up with the macroassembler. So don't rely on my picks for the NFL postseason if you want to keep your money. If we make it to Fx16, then Fx16 will get a regular beta-and-RC cycle, and the stable branch will move to 16 and then settle again on 17. It would be a miracle if we made it to Firefox 24, though (it's doubtful Mozilla would still even support 10.6 by then, and we're not going to make a "Lionized" TenFourFox because that would make me nauseous), but we would still do security updates, of course.
There are a few other things I'd like you guys to think about. I have had some internal discussions with Mozilla and TenFourFox is currently their draft recommendation for Power Mac and 10.4 users still on 3.6 (always subject to change, of course, but this seems like their intent). Right now we piggyback on SUMO, Mozilla's support system, but this doesn't seem fair when Mozilla won't support PowerPC at all. Instead, we're going to need to start up our own user support and triage network like I already have set up for Classilla ("Report-A-Bug"), just on a much larger scale. I'm soliciting for someone or a group of someones to head up triaging user reports and helping support the influx of new users we will likely receive, translating user reports into bug reports as appropriate. Please E-mail me or nominate yourself in the comments. You will get free beer if we ever find a bar that would serve our PowerPC-using riffraff kind.
The second thing I'd like people to consider is what to backport in case we don't make it to Firefox 17 (or when we don't make it to Firefox 24), i.e., when we drop to feature parity. We would need to implement important CSS and layout features from later Mozilla releases to keep the browser core reasonably current, possibly new JavaScript features, and definitely some important extension-like functionality to incorporate into the interface and maintain ourselves (the QTE, adblock along the lines of Camino's, user agent switching to mimic later browsers, etc.). This is not a Christmas list and Christmas has already left the building; it is a "need to have or we lose significant functionality" list. I'm not soliciting for this list yet because we're still at source parity for the time being. If it looks like we fall off the wagon, we'll need to powwow.
I'm shooting for 10 beta next week. I'll post if there will be a significant delay.
Tuesday, December 27, 2011
AWOAFY? (Are We Old And Fast Yet?, or, 9.0.1pre JM+TI available)
During the long death march to Firefox 4, Mozilla made much hay out of their Are We Fast Yet? site, a/k/a AWFY. AWFY was their daily dangling carrot while they worked on the first iteration of methodjit and offered regular feedback against the competition, and is still being used in the new type inference age. Well, JM+TI is here for PowerPC at last (that is, JaegerMonkey and type inference), and so is 9.0.1pre with new backends for your experimental pleasure. There are no other changes in this release and it is otherwise exactly the same as 9.0; it should fix all the known flaws in methodjit. (It does not include the fix Mozilla issued in Firefox 9.0.1 because I have received no relevant reports of crashes related to it, and it may impact performance, so there will not be a 9.0.1 unless I hear differently.)
So, with this release, I am now proud to bring you Are We Old And Fast Yet? where the first answer is yes and the second answer is "not enough." JM+TI now offers JavaScript speeds comparable to our old friend tracejit: on the quad G5, JM+TI (without tracejit) now matches the 1050ms on SunSpider that tracejit gets, and increases Dromaeo to 132 runs/sec. On our testing 1GHz G4/7450, Dromaeo rises to 38 runs/sec, and SunSpider drops slightly to 2750. (We're solving the missing square root problem for the present time by simply falling through to the JavaScript square root library routine. The G5 uses its native square root instruction, of course.)
This is already pretty darn good, but we can do better, and here is our goal for AWOAFY: quad G5 at Highest achieves less than 1000ms on SunSpider; 1GHz G4/7450 achieves less than 2500ms. These are totally doable; in fact, improvements in Firefox due to ship in the Fx11 timeframe may push these numbers down to target without us doing anything, but we're still going to shoot for low-hanging fruit optimizations in TenFourFox 10.
That brings us to what happens next. If Firefox 10 is indeed the ESR, as our Magic 8-ball predicts (it also predicted I would get a date with Scarlett Johansson, though), there are enough pieces of tracejit that it should still work and I think we should stick with tracejit as the default JIT for the duration of the 10 branch if so (with the option for JM+TI baked in for the adventurous): it's well tested, it's safe and it does well on our older hardware. I am waiting for beta 2 to be certified on mozilla-beta and once it is, we will begin the port. On deck for this release are some fixes from Ben and getting Tobias' fixed VMX text conversion routines back in action.
If Firefox 10 is not the ESR, then Fx10 will be the last tracejit release, and people will be forced to use JM+TI starting with Fx11. Sorry, this is Mozilla's call, not mine.
Either way, when we scramble to the ESR, the ESR will become our stable branch. Mozilla will backport security and stability fixes to the ESR which we will pick up, and unlike Mozilla, we will do other kinds of bugfixes to TenFourFox "ESR" that we deem appropriate. There will be no new features added, however. Most users will stay on this release.
For you, the rowdy, wild beta testers, there will still be beta releases, but not formal releases (because there won't be formal releases for awhile -- users will be kept on the ESR-based release). The situation we are trying to avoid is getting stuck on a release of Firefox that isn't getting security updates because we are unable to get the next one working. If, say, we get to Firefox 14 but can't make it to 15 -- and this is a real risk because Mozilla is already making noise about canning 10.5 support somewhere around Fx13, as we have previously discussed -- then we are marooning our users on a branch that will never get any fixes. By keeping later updates merely betas, most users are on a maintained branch and those of us out on the beta channel can just downgrade to the already existing release and live out our days in secure geriatric bliss in feature parity.
Assuming the ESR is 10, the next ESR would be Fx17. If we make it to Fx16, then we will do a regular beta release for Fx16, release Fx16, and go for 17. We can certainly backport security fixes from Fx17 to Fx16 if we fail at Fx17 and stay safe; the code is similar enough. If we don't make it to Fx16, then we can go on to feature parity against the ESR using the patches we've already done for later releases. So I feel pretty good about the future.
JM+TI is only transitional, however, because the future is Mozilla's new IonMonkey engine. This is months away from being functional, but I already looked at some of the code for the existing partially-functional backends and while much of our JM+TI work will transfer, there is a lot of work to do to get it working for PowerPC. Let's try to get as much wear out of the work we've already done.
Now, let's test AWOAFY. Download 9.0.1pre and go to about:config. Turn javascript.options.methodjit.chrome and .content to true, and turn javascript.options.tracejit.chrome and .content to false (yes, you are disabling tracejit; it is not compatible with type inference). Finally, set javascript.options.typeinference to true and restart the browser. Report your results! Remember to turn type inference off if you need to downgrade to 9.0, and turn methodjit off entirely if you downgrade to 9.0b1 or earlier.
So, with this release, I am now proud to bring you Are We Old And Fast Yet? where the first answer is yes and the second answer is "not enough." JM+TI now offers JavaScript speeds comparable to our old friend tracejit: on the quad G5, JM+TI (without tracejit) now matches the 1050ms on SunSpider that tracejit gets, and increases Dromaeo to 132 runs/sec. On our testing 1GHz G4/7450, Dromaeo rises to 38 runs/sec, and SunSpider drops slightly to 2750. (We're solving the missing square root problem for the present time by simply falling through to the JavaScript square root library routine. The G5 uses its native square root instruction, of course.)
This is already pretty darn good, but we can do better, and here is our goal for AWOAFY: quad G5 at Highest achieves less than 1000ms on SunSpider; 1GHz G4/7450 achieves less than 2500ms. These are totally doable; in fact, improvements in Firefox due to ship in the Fx11 timeframe may push these numbers down to target without us doing anything, but we're still going to shoot for low-hanging fruit optimizations in TenFourFox 10.
That brings us to what happens next. If Firefox 10 is indeed the ESR, as our Magic 8-ball predicts (it also predicted I would get a date with Scarlett Johansson, though), there are enough pieces of tracejit that it should still work and I think we should stick with tracejit as the default JIT for the duration of the 10 branch if so (with the option for JM+TI baked in for the adventurous): it's well tested, it's safe and it does well on our older hardware. I am waiting for beta 2 to be certified on mozilla-beta and once it is, we will begin the port. On deck for this release are some fixes from Ben and getting Tobias' fixed VMX text conversion routines back in action.
If Firefox 10 is not the ESR, then Fx10 will be the last tracejit release, and people will be forced to use JM+TI starting with Fx11. Sorry, this is Mozilla's call, not mine.
Either way, when we scramble to the ESR, the ESR will become our stable branch. Mozilla will backport security and stability fixes to the ESR which we will pick up, and unlike Mozilla, we will do other kinds of bugfixes to TenFourFox "ESR" that we deem appropriate. There will be no new features added, however. Most users will stay on this release.
For you, the rowdy, wild beta testers, there will still be beta releases, but not formal releases (because there won't be formal releases for awhile -- users will be kept on the ESR-based release). The situation we are trying to avoid is getting stuck on a release of Firefox that isn't getting security updates because we are unable to get the next one working. If, say, we get to Firefox 14 but can't make it to 15 -- and this is a real risk because Mozilla is already making noise about canning 10.5 support somewhere around Fx13, as we have previously discussed -- then we are marooning our users on a branch that will never get any fixes. By keeping later updates merely betas, most users are on a maintained branch and those of us out on the beta channel can just downgrade to the already existing release and live out our days in secure geriatric bliss in feature parity.
Assuming the ESR is 10, the next ESR would be Fx17. If we make it to Fx16, then we will do a regular beta release for Fx16, release Fx16, and go for 17. We can certainly backport security fixes from Fx17 to Fx16 if we fail at Fx17 and stay safe; the code is similar enough. If we don't make it to Fx16, then we can go on to feature parity against the ESR using the patches we've already done for later releases. So I feel pretty good about the future.
JM+TI is only transitional, however, because the future is Mozilla's new IonMonkey engine. This is months away from being functional, but I already looked at some of the code for the existing partially-functional backends and while much of our JM+TI work will transfer, there is a lot of work to do to get it working for PowerPC. Let's try to get as much wear out of the work we've already done.
Now, let's test AWOAFY. Download 9.0.1pre and go to about:config. Turn javascript.options.methodjit.chrome and .content to true, and turn javascript.options.tracejit.chrome and .content to false (yes, you are disabling tracejit; it is not compatible with type inference). Finally, set javascript.options.typeinference to true and restart the browser. Report your results! Remember to turn type inference off if you need to downgrade to 9.0, and turn methodjit off entirely if you downgrade to 9.0b1 or earlier.
Subscribe to:
Posts (Atom)