Saturday, July 25, 2015

Updating you on 38 just-in-time

Did you see what I did there? For the past two weeks my free time apart from work and the Master's degree has been sitting in a debugger trying to fix JavaScript, which is just murder on my dating life. Here is the current showstopper bug-roll for 38.1.1b1:

  • The Faceblech bug with the new IonPower JavaScript JIT compiler is squashed, I think, after repairing some conformance test failures which in turn appear to have repaired Forceblah. In my defence, the two bugs in question were incredibly weird edge cases and these tests are not part of the usual JIT test suite, so I guess we'll have to run them as well in future. This also repairs an issue with Instagrump which is probably the same underlying issue since Faceboink owns them also.

    The silver lining after all that was that I was considering disabling inlining in the JIT prior to release, which worked around the "badness," but also cut the engine speed in about half. (Still faster than JaegerMonkey!) To make this a bit less of a hit, I tuned the thresholds for starting the twin JITs and got about 10% improvement without inlining. With inlining back on, it's still faster by about 4% and change -- the G5 now achieves a score of nearly 5800 on V8, up from 5560. I also tweaked our foreground finalization patch for generational GC so that we should be able to get the best of both worlds. Overall you should see even better performance out of this next beta.

  • I have a presumptive fix for the webfont "ATSUI puke" on the New York Times, but it's not implemented or well-tested yet. This is a crash on 10.5, so I consider it a showstopper and it will be fixed before the next beta. (It affects 31.8 also but I will not be making another 31 release unless there is a Mozilla ESR chemspill.)

  • The modified strip7 tool required for building 38.x has a serious bug in it that causes it to crash trying to strip certain symbols. I have fixed this bug and builders will need to install this new version (remember: do not replace your normal strip with this one; it is intentionally loose with the Mach-O specification). I will be uploading it sometime this week along with an updated gdb7 that has better debugger performance and repairs a bug with too eagerly disabling register display while single-stepping Ion code.

These bugs are not considered showstoppers, but I do acknowledge them and I plan to fix them either for the final release or the next version of 38:

  • I can confirm saved passwords do not appear in the preferences panel. They do work, though, and can be saved, so this is more of an issue with managing them; while it's possible to do so manually it requires some inconvenient screwing around with your profile, so I consider this the highest priority of the non-showstopper bugs.

  • Checkboxes on the dropdown menus from the Console tabs do not appear. This specific manifestation is purely cosmetic because they work normally otherwise, but this may be an indication there is a similar issue with dropdowns and context menus elsewhere, so I do want to fix this as well.

Other miscellaneous changes include some adjustments to HTML5 media streaming and I have decided to reduce the default window and tab undos back to 31's level (6 and 2 respectively) so that the browser still gives up tenured memory a bit more easily. Unfortunately, there is not enough time to get MP3 support fully functional for final release. I plan to get this completed in a future version of 38.x, but it will not be officially supported until then (you can still toggle tenfourfox.mp3.enabled to use the minimp3 driver for those sites it does work with as long as you remember that seeking within a track doesn't work yet).

The localizer elves have French, German, Spanish, Italian, Russian and Finnish installers available. Our Japanese localization appears to have dropped off the web, so if you can help us, o-negai shimasu! Swedish just needs a couple of strings to be finished. We do not yet have Polish or Asturian, which we used to, so if you can help on any of these languages, please visit issue 42 where Chris is coordinating these efforts. A big thank you to all of our localizers!

Once the localizations are all in, the Google Code project will be frozen to prepare for the wiki and issue tracker moving to Github ahead of Google Code going read-only on 24 August. Downloads will remain on SourceForge, but everything else will go to Github, including the source tree when we eventually drop source parity. I was hoping to have an Elcapitanspoof up in time for 38's final release, but we'll see if I have time to do the graphics.

Watch for the next beta to come out by next weekend with any luck, which gives us enough time if there needs to be a third emergency release prior to the final (weekend prior to 11 August).

Finally, I am pleased to note we are now no longer the only PowerPC JavaScript JIT out there, though we are the only one I know of for Mozilla SpiderMonkey. IBM has been working on a port of Google V8 to PowerPC for some time, both AIX and Linux, which recently became an official part of the Google V8 repository (i.e., the PPC port is now officially supported). If you've been looking at nabbing a POWER8 with that money burning a hole in your pocket, it even works with the new Power ISA little endian mode, of which we dare not speak. Since uppsala, Floodgap's main server, is a POWER6 running AIX and should be able to run this, I might give it a spin sometime when I have a few spare cycles. However, before some of the freaks amongst you get excited and think this means Google Chrome on OS X/ppc is just around the corner, there's still an awful lot more work required to get it operational than just the JavaScript engine, and it won't be me that works on it. It does mean, however, that things like node.js will now work on a Power-based server with substantially less fiddling around, and that might be very helpful for those of you who run Power boxes like me.

Monday, July 6, 2015

Beta 1 aftermath

So let's sum up the first 38 beta.

Confirmed bugs: Facesuck seems to be totally whacked in Ion mode (it works fine in Baseline only mode). IonPower passes all the JIT tests, though, so this must be something that the test suite does not cover. I'm investigating some other conformance test suites and corrected a couple other variances so far between Baseline and Ion but none of them appear to be what's ailing Faceblech yet.

Also, we have another web font that makes ATSUI puke, except it has an inconveniently null PostScript name so we can't filter it with the existing method. Fortunately Tobias had come up with an alternative font filter system some time ago that should work with 10.4.

Not confirmed (yet?): a few people have reported that memory usage skyrockets upon quit and the browser crashes (inevitably after exceeding its addressing space), on a variety of systems, both 10.4 and 10.5. I can't reproduce this on any of the test machines.

I need to do more looking into the stored passwords question.

Since we're out of runway, i.e., ESR31, and we need one more beta before release, I'm going to keep working on the Facebork problem (or at least try to fix it by fixing something else) until July 24. If we can't do it by then, I guess we launch without IonPower, which is unfortunate and will regress JavaScript performance, but we will still at least have Baseline. Faceburp is just too big to debug in place, so I need you folks to find another site that has similar problems. I haven't been able to yet myself.

Sunday, June 28, 2015

Hello, 38 beta, it's nice to meet you

And at long last the 38 beta is very happy to meet you too (release notes, downloads, hashes). Over the next few weeks I hope you and the new TenFourFox 38 will become very fond of each other, and if you don't, then phbbbbt.

There are many internal improvements to 38. The biggest one specific to us, of course, is the new IonPower JavaScript JIT backend. I've invested literally months in making TenFourFox's JavaScript the fastest available for any PowerPC-based computer on any platform, not just because every day websites lard up on more and more crap we have to swim through (viva Gopherspace) but also because a substantial part of the browser is written in JavaScript: the chrome, much of the mid-level plumbing and just about all those addons you love to download and stuff on in there. You speed up JavaScript, you speed up all those things. So now we've sped up many browser operations by about 11 times over 31.x -- obviously the speed of JavaScript is not the only determinant of browser speed, but it's a big part of it, and I think you'll agree that responsiveness is much improved.

JavaScript also benefits in 38 from a compacting, generational garbage collector (generational garbage collection was supposed to make 31 but was turned off at the last minute). This means recently spawned objects will typically be helplessly slaughtered in their tender youth in a spasm of murderous efficiency based on the empiric observation that many objects are created for brief usage and then never used again, reducing the work that the next-stage incremental garbage collector (which we spent a substantial amount of time tuning in 31 as you'll recall, including backing out background finalization and tweaking the timeslice for our slower systems) has to do for objects that survive this pediatric genocide. The garbage collector in 38 goes one step further and compacts the heap as well, which is to say, it moves surviving objects together contiguously in memory instead of leaving gaps that cannot be effectively filled. This makes both object cleanup and creation much quicker in JavaScript, which relies heavily on the garbage collector (the rest of the browser uses more simplistic reference counting to determine object lifetime), to say nothing of a substantial savings in memory usage: on my Quad G5 I'm seeing about 200MB less overhead with 48 tabs open.

I also spent some time working on font enumeration performance because of an early showstopper where sites that loaded WOFF fonts spun and spun and spun. After several days of tearing my hair out in clumps the problem turned out to be a glitch in reference counting caused by the unusual way we load platform fonts: since Firefox went 10.6+ it uses CoreText exclusively, but we use almost completely different font code based on the old Apple Type Services which is the only workable choice on 10.4 and the most stable choice on 10.5. ATS is not very fast at instantiating lots of fonts, to say the least, so I made the user font cache stickier (please don't read that as "leaky" -- it's sticky because things do get cleaned up, but less aggressively to improve cache hit percentage) and also made a global font cache where the font's attribute tag directory is cached browser-wide to speed up loading font tables from local fonts on your hard disk. Previously this directory was cached per font entry, meaning if the font entry was purged for re-enumeration it had to be loaded all over again, which usually happened when the browser was hunting for a font with a particular character. This process used to take about fifteen to twenty seconds for the 700+ font faces on my G5. With the global font cache it now takes less than two.

Speaking of showstoppers, here's an interesting one which I'll note here for posterity. nsChildView, the underlying system view which connects Cocoa/Carbon to Gecko, implements the NSTextInput protocol which allows it to accept Unicode input without (as much) mucking about with the Carbon Text Services Manager (Firefox also implements NSTextInputClient, which is the new superset protocol, but this doesn't exist in 10.4). To accept Unicode input, under the hood the operating system actually manipulates a special undocumented TSM input context called, surprisingly, NSTSMInputContext (both this and the undocumented NSInputContext became the documented NSTextInputContext in 10.6), and it gets this object from a previously undocumented method on NSView called (surprise again) inputContext. Well, turns out if you override this method you can potentially cause all sorts of problems, and Mozilla had done just that to handle complex text input for plugins. Under the 10.4 SDK, however, their code ended up returning a null input context and Unicode input didn't work, so since we don't support plugins anyhow the solution was just to remove it completely ... which took several days more to figure out. The moral of the story is, if you have an NSView that is not responding to setMarkedText or other text input protocol methods, make sure you haven't overridden inputContext or screwed it up somehow.

I also did some trivial tuning to the libffi glue library to improve the speed of its calls and force it to obey our compiler settings (there was a moment of panic when the 7450 build did not start on the test machines because dyld said XUL was a 970 binary -- libffi had seen it was being built on a G5 and "helpfully" compiled it for that target), backed out some portions of browser chrome that were converted to CoreUI (not supported on 10.4), and patched out the new tab tile page entirely; all new tabs are now blank, like they used to be in previous versions of Firefox and as intended by God Himself. There are also the usual cross-platform HTML5 and CSS improvements you get when we leap from ESR to ESR like this, and graphics are now composited off-main-thread to improve display performance on multiprocessor systems.

That concludes most of the back office stuff. What about user facing improvements? Well, besides the new blank tabs "feature," we have built-in PDF viewing as promised (I think you'll find this more useful to preview documents and load them into a quicker viewer to actually read them, but it's still very convenient) and Reader View as the biggest changes. Reader View, when the browser believes it can attempt it, appears in the address bar as a little book icon. Click on it and the page will render in a simplified view like you would get from a tool such as Readability, cutting out much of the extraneous formatting. This is a real godsend on slower computers, lemme tell ya! Click the icon again to go back. Certain pages don't work with this, but many will. I have also dragged forward my MP3 decoder support, but see below first, and we have prospectively landed Mozilla bug 1151345 to fix an issue with the application menu (modified for the 10.4 SDK).

You will also note the new, in-content preferences (i.e., preferences appears in a browser tab now instead of a window, a la, natch, Chrome), and that the default search engine is now Yahoo!. I have not made this default to anything else since we can still do our part this way to support MoCo (but you can change it from the preferences, of course).

I am not aware of any remaining showstopper bugs, so therefore I'm going ahead with the beta. However, there are some known issues ("bugs" or "features" mayhaps?) which are not critical. None of these will hold up final release currently, but for your information, here they are:

  • If you turn on the title bar, private browsing windows have the traffic light buttons in the wrong position. They work; they just look weird. This is somewhat different than issue 247 and probably has a separate, though possibly related, underlying cause. Since this is purely cosmetic and does not occur in the browser's default configuration, we can ship with this bug present but I'll still try to fix it since it's fugly (plus, I personally usually have the title bar on).

  • MP3 support is still not enabled by default because seeking within a track (except to the beginning) does not work yet. This is the last thing to do to get this support off the ground. If you want to play with it in its current state, however, set tenfourfox.mp3.enabled to true (you will need to create this pref). If I don't get this done by 38.0.2, the pref will stay off until I do, but the rest of it is working already and I have a good idea how to get this last piece functional.

  • I'm not sure whether to call this a bug or a feature, but scaling now uses a quick and dirty algorithm for many images and some non-.ico favicons apparently because we don't have Skia support. It's definitely lower quality, but it has a lot less latency. Images displayed by themselves still use the high-quality built-in scaler which is not really amenable to the other uses that I can tell. Your call on which is better, though I'm not sure I know how to go back the old method or if it's even possible anymore.

  • To reduce memory pressure, 31 had closed tab and window undos substantially reduced. I have not done that yet for 38 -- near as I can determine, the more efficient memory management means it is no longer worth it, so we're back to the default 10 and 3. See what you think.

Builders: take note that you will need to install a modified strip ("strip7") if you intend to make release binaries due to what is apparently a code generation bug in gcc 4.6. If you want to use a different (later) compiler, you should remove the single changeset with the gcc 4.6 compatibility shims -- in the current changeset pack it's numbered 260681, but this number increments in later versions. See our new HowToBuildRightNow38 for the gory details and where to get strip7.

Localizers: strings are frozen, so start your language pack engines one more time in issue 42. We'd like to get the same language set for 38 that we had for 31, and your help makes it possible. Thank you!

As I mentioned before, it's probably 70-30 against there being a source parity version after 38ESR because of the looming threat of Electrolysis, which will not work as-is on 10.4 and is not likely to perform well or even correctly on our older systems. (If Firefox 45, the next scheduled ESR, still allows single process operation then there's a better chance. We still need to get a new toolchain up and a few other things, though, so it won't be a trivial undertaking.) But I'm pleased with 38 so far and if we must go it means we go out on a high note, and nothing says we can't keep improving the browser ourselves separate from Mozilla after we split apart (feature parity). Remember, that's exactly what Classilla does, except that we're much more advanced than Classilla will ever be, and in fact Pale Moon recently announced they're doing the same thing. So if 38 turns out to be our swan song as a full-blooded Mozilla tier 3 port, that doesn't mean it's the end of TenFourFox as a browser. I promise! Meanwhile, let's celebrate another year of updates! PowerPC forever!

Finally, looking around the Power Mac enthusiast world, it appears that SeaMonkeyPPC has breathed its last -- there have been no updates in over a year. We will pour one out for them. On the other hand, Leopard Webkit continues with regular updates from Tobias, and our friendly builder in the land of the Rising Sun has been keeping up with Tenfourbird. We have the utmost confidence that there will be a Tenfourbird 38 in your hands soon as well.

Some new toys to play with are next up in a couple days.

Friday, June 26, 2015

31.8.0 available (say goodbye)

31.8.0 is available, the last release for the 31 series (release notes, downloads, hashes). Download it and give it one last spin. 31 wasn't a high water mark for us in terms of features or performance, but it was pretty stable and did the job, so give it a salute as it rides into the sunset. It finalizes Monday PM Pacific time as usual.

I'm trying very hard to get you the 38.0.1 beta by sometime next week, probably over the July 4th weekend assuming the local pyros don't burn my house down with errant illegal fireworks, but I keep hitting showstoppers while trying to dogfood it. First it was fonts and then it was Unicode input, and then the newtab crap got unstuck again, and then the G5 build worked but the 7450 build didn't, and then, and then, and then. I'm still working on the last couple of these major bugs and then I've got some additional systems to test on before I introduce them to you. There are a couple minor bugs that I won't fix before the beta because we need enough time for the localizers to do their jobs, and MP3 support is present but is still not finished, but there will be a second beta that should address most of these problems prior to our launch with 38.0.2. Be warned of two changes right away: no more tiles in the new tab page (I never liked them anyway, but they require Electrolysis now, so that's a no-no), and Check for Updates is now moved to the Help menu, congruent with regular Firefox, since keeping it in its old location now requires substantial extra code that is no longer worth it. If you can't deal with these changes, I will hurt you very slowly.

Features that did not make the cut: Firefox Hello and Pocket, and the Cisco H.264 integration. Hello and Pocket are not in the ESR, and I wouldn't support them anyway; Hello needs WebRTC, which we still don't really support, and you can count me in with the people who don't like a major built-in browser component depending exclusively on a third-party service (Pocket). As for the Cisco integration, there will never be a build of those components for Tiger PowerPC, so there. Features that did make the cut, though, are pdf.js and Reader View. Although PDF viewing is obviously pokier compared to, it's still very convenient, generally works well enough now that we have IonPower backing it, and is much safer. However, Reader View on the other hand works very well on our old systems. You'll really like it especially on a G3 because it cuts out a lot of junk.

After that there are two toys you'll get to play with before 38.0.2 since I hope to introduce them widely with the 38 launch. More on that after the beta, but I'll whet your appetite a little: although the MacTubes Enabler is now officially retired, since as expected the MacTubes maintainer has thrown in the towel, thanks to these projects the MTE has not one but two potential successors, and one of them has other potential applications. (The QuickTime Enabler soldiers on, of course.)

Last but not least, I have decided to move the issues list and the wiki from Google Code to Github, and leave downloads with SourceForge. That transition will occur sometime late July before Google Code goes read-only on August 24th. (Classilla has already done this invisibly but I need to work on a stele so that 9.3.4 will be able to use Github effectively.) In the meantime, I have already publicly called Google a bunch of meaniepants and poopieheads for their shameful handling of what used to be a great service, so my work here is done.

Monday, June 15, 2015

Mission accomplished: IonPower kicks incredibly large gluteus

I like kicking big butts on big endian processors and I cannot lie. You other brothers/sisters/etc. are unable to deny.

Remember our primary target was to make our new IonPower JavaScript JIT backend eclipse our previous speed champion, JaegerMonkeyPPC, on our chosen classic V8 benchmark. It's always hard to judge debugging builds because of all the extra chaff they carry, but as of early this morning TenFourFox 38 was able to get a G5-optimized build up (more on that in a moment which builders need to read). Let's get a drum roll, maestro. Test system is a Quad G5 with performance set to Highest. Here is our current browser (31.7.0) running the current JIT compiler, PPCBC:

% /Applications/ --no-ion -f run.js
Richards: 208
DeltaBlue: 579
Crypto: 365
RayTrace: 574
EarleyBoyer: 628
RegExp: 622
Splay: 932
NavierStokes: 439
Score (version 7): 502

PPCBC beats the interpreter by a long shot, which our long suffering friends running Firefox in PowerPC Linuxland must still contend with, but PPCBC was no JaegerMonkey. Here is 17.0.11:

% /Applications/ -m -n -f run.js
Richards: 3160
DeltaBlue: 8364
Crypto: 3036
RayTrace: 1784
EarleyBoyer: 3602
RegExp: 553
Splay: 4115
NavierStokes: 1383
Score (version 7): 2519

Yup, that was good times. But are you ready for awesome?

% mozilla-38b/obj-ff-dbg/dist/bin/js -f run.js
Richards: 7258
DeltaBlue: 19207
Crypto: 2857
RayTrace: 15730
EarleyBoyer: 8873
RegExp: 1202
Splay: 3960
NavierStokes: 3456
Score (version 7): 5561

That is 2.21 times faster than JaegerMonkey (versions 10-22) and over eleven (!!) times faster than PPCBC (versions 24-36). I don't think you even want to see how much faster it is than the interpreter ... but what the heck!

% mozilla-38b/obj-ff-dbg/dist/bin/js --no-ion --no-baseline --no-native-regexp -f run.js
Richards: 44.7
DeltaBlue: 172
Crypto: 80.9
RayTrace: 113
EarleyBoyer: 173
RegExp: 192
Splay: 341
NavierStokes: 135
Score (version 7): 134

That's over 41 times faster. I can't wait to get this hot little rocket in your hot little hands. Mind the fire. PowerPC got back.

The only target we missed is that Baseline-only performance is still about 25% slower than PPCBC, which admittedly was highly optimized for that purpose. I think this tradeoff will be acceptable. :)

Builders are warned: 38 will probably require some tweaks to bintools due to a problem with N_SECT and gcc 4.6. I'm currently experimenting with a modified strip that doesn't choke on these non-standard object files and will provide this to you when the beta becomes available. In addition, I've pretty much settled on gcc 4.9 for post-38 and we will likely use a combination of MacPorts and Sevan's pkgsrc builds for the new build system, if there is one. More on that after 38 launches successfully.

Sunday, June 14, 2015

Hello from TenFourFox 38

After some feverish work over the weekend, TenFourFox 38 is now stable enough to make this blog post. (Much of this work was done late last night listening to the best foreign affairs show on radio, the Dark Secret Place with Bryan Suits, heard here in the Los Angeles hive of villainy from 10-midnight on KFI AM 640 on Saturdays. Bryan points out there are more Chinese state security agents in California than FBI agents, which probably explains the national priorities that facilitated the OPM private data hack, and as someone asked to keep state secrets to myself it burns my cookies to a freaking crisp that the federal government can't preserve my own.) JavaScript once again now passes all tests with the new IonPower engine, and most of the major showstopper bugs are fixed. There are some minor polish problems and one intermittent crash with fonts but it only occurs in the debugger, not when the app is run raw, suggesting that our hacked gdb has a couple bugs in it (quite possible). Performance is always hard to judge with a debug build, but I have the Quad throttled into low power because of the 90+ degree Fahrenheit weather and even with its clock speed capped it's still good enough to type this!

Next step is to load MP3 support into 38 and try to get an opt build off the ground, then pull the latest 38ESR, port these beta changesets to that, and make a public release. Father's Day and a class paper are in the way, but I'm shooting for getting something into your hands in a week or so. MP3 support may not be in the initial beta (or may not be fully finished), but I fully intend to complete that somewhere in the 38 timeframe since it obviously works.

Along with 10.4Fx 38 I've also been working on a more generic solution for video and Flash-only content, as well as a personal labour of love for the first computer I ever had as a kid. You'll get to play with both of these very shortly.

Monday, June 1, 2015

TenFourFox 38 is GO! (plus: SourceForge gets sleazy)

Wow, it's been awhile -- sorry for the lack of updates, I've just been snowed in with classes and the day job.

First, some good news: TenFourFox 38 successfully compiled and linked, and took its first halting steps last night. There are still some critical bugs in it; among others, there is a glitch with the application menus that Mozilla seems to have regressed on 10.4 between Fx36 and 38, and JIT changes have caused IonPower to fail six tests it used to pass (and needs to pass to run the browser chrome). However, these issues are almost certainly solveable and we should be officially on target for switching from 31ESR to 38ESR after 31.8.0 with another year of Mozilla updates in the bag. Once again Power Mac users will be fully current with Firefox ESR, meaning even the very last G5 to roll off the assembly line in 2006 will have enjoyed at least 10 years of Gecko-powered browsing (and even if Fx38 is the last source-parity TenFourFox, we'll still be doing feature parity releases for a good long while afterwards). Although I will not be able to work much on the browser for the next couple weeks due to my Master's program getting in the way again, I'm still hoping for a beta release by July so that we have enough time for the localizers to work their magic once more.

In the storm clouds department, I continue to monitor the functional state of Electrolysis (multi-process Firefox) closely; I still believe, and some of the code I've had to hack around only confirms this, that Electrolysis will not work correctly on the 10.4 SDK (nor likely, for that matter, faster, since many Power Macs still in use are single core) even if the underlying system functions are implemented in userland. However, Mozilla is now in the midst of developing Fx41, and Electrolysis still has some major issues preventing it from primetime; the current calendar has Electrolysis reaching the release channel no earlier than Fx42, and I'm betting this is probably a release or two behind. If Mozilla still allows the main browser to start single-process in 45ESR, then we have a shot at one more ESR. If it allows the main browser to start single-process only in safe mode, we may be able to hack around that, but add-on compatibility might be impacted. If neither is allowed, we drop source parity with 38.

TenFourFox 38 and derivatives are also the last release(s) that will support gcc 4.6. Mozilla already dropped support for it, but I really didn't want to certify a new compiler and toolchain on top of a new stable release branch, and the support change was late enough in development that most of the browser still builds. The 4.6 changes are being segregated into a single changeset so that they can be quickly discarded when a later compiler comes online, which will be mandatory for any test releases we make beyond 38 (we might use Sevan Janiyan's pkgsrc gcc since MacPorts is kind of a dog's breakfast for PowerPC nowadays -- more on this later). Speaking of, now that the last remnants of our old JaegerMonkey and PPCBC JIT backends are purged from the changeset pack, we've cut our merge overhead by about 30 percent. Now, that's a diet.

G3 owners should also be warned that Mozilla is doing more with SIMD in JavaScript, and our hot new IonPower JavaScript compiler may be required post-38 to support it. SIMD, of course, is implemented in the PowerPC ISA as AltiVec/VMX, but G3 systems don't have AltiVec support, which may mean no JavaScript compilation. That would be a very suboptimal configuration to ship particularly on the lowest spec platforms that need a JIT the very most. Although I would not prevent the browser from being built for G3 without JIT support should someone wish to do so, I may stop offering G3 builds myself if SIMD support became mandatory (G4/7400 builds would still continue), especially as it represents 25% of total buildtime and is consistently our least used configuration. This does not apply to TenFourFox 38 -- G3 folks are still guaranteed at least that much, and if we drop source parity, G3 builds will likely continue since there would be no technical reason to drop them then. But, if you can find a G4 for your Yosemite's ZIF socket, now might be a good time. :)

Finally, the transition off Google Code should be complete by July as well. However, I'm displeased to see that SourceForge has engaged in some fairly questionable behaviour with hosted downloads, admittedly with abandoned Windows-based projects, but definitely without project owner consent. I'm not going to begrudge them a buck for continuing to allow free binary hosting by displaying ads, but I intensely dislike them monkeying with existing binaries without opting into it.

It is highly unlikely we would ever be victimized in that fashion since our now exotic architecture would make it very technically difficult for them to do so, but since it's easy to get things into SourceForge, just not out of it, I'm now considering using Github (despite my Mercurial preference) for tickets and wiki and eventually source code, and just leaving binaries on SourceForge as long as they remain unmolested, since Google Code does offer an export-to-Github option. If Github doesn't work out, we can import to SourceForge from there, if we have to; Classilla will probably transition the same way. But I have to say with sadness tinged with disgust that I'm really disappointed in them. Once upon a time, they were the go-to site for FOSS, and now they're scrabbling around in the muck for a dollar. Lo, how the mighty have fallen.