Friday, November 16, 2012

17.0 RC available and "locking" up

... from the usual place and with the usual notes. Also try the translations! This version will be released to the public on Monday and become the new stable branch. Excellent!

As stated in the prior blog entry, this version restores the kernel-based atomic locking used in TenFourFox 10 (issue 191). And, well, there's an interesting story associated with that. At baseline Mozilla NSPR implements locking, including atomic increment/decrement/set/add operations, in terms of pthread_mutex_*, which is just fine on Linux and *BSD but is apparently abysmally bad on OS X. These thread-safe operations are being called more and more by Gecko as they attempt to leverage a greater number of processor threads to make operations more asynchronous, improve browser responsiveness and take better advantage of multicore systems, and are essential to keep threads from walking all over each other. But the overhead, apparently worsened by an inefficient implementation in the OS X kernel, is rapidly becoming unacceptable. I patched the parts in JavaScript out for 17 final and you're using that now.

In gcc 4.1, the compiler implements faster intrinsics for atomic operations (the __sync_*() series of functions), and NSPR can use these for a fast path, but we don't have those in gcc 4.0.1. So the solution will be to extend the quick locking patch I wrote up for JavaScript over the entire browser, which should significantly reduce locking contention because less things will be trying to get mutexes for operations that don't need them. We would just use our own atomic operations and the operating system's atomic operations in place of NSPR's use of pthread_mutex_*, everywhere we would do any atomic operation.

Interestingly, AuroraFox won't have to do this, and neither will TenFourFox 18, because both of them are built with gcc 4.6 and can use the compiler's intrinsics. This will only be an issue for 17ESR because it is the last branch to be built with 4.0.1. I'm hoping to get this working maybe next week sometime for a test release prior to beginning work on 18, because I'd like to fix it for 17.0.1.

The larger problem of such locks being slow in general, however, means we'll probably have to come up with a better way of handling locking on PPC OS X, or see if some of the areas that use PR_Lock and friends could be better written with atomic intrinsics. Mozilla might even want some of these patches, since it doesn't look like Apple improved this a lot (Grand Central Dispatch is just a lightweight way around the problem).


  1. Not sure if this is the place to ask this so please forgive me:

    Knowing the rationale for Ten Four Fox, I am going to make this request anyway. I have been using TFF very successfully on an iMac G5 PPC but have recently changed to an iMac Intel Core Duo with a combo pack of Mac Tiger Intel + iLife 06 the OS that came with the computer. Obviously I now cannot use TFF, so am using OmniWeb 5.11.2 which uses (I am not much of a techie) the same web kit as Safari 5 (OmniWeb just flies on my Intel Imac, suspect it was built for Intel machines) so OmniWeb is to Safari what TFF is to Firefox. I also have FF 3.6.28 on my computer as a back up. So might it be possible in the evolution of TFF to offer an Intel version for those of us quite content to continue using Mac Tiger Intel 10.4.11. I require an Intel Mac to run certain software unavailable on the PPC format (eg: Picasa, new versions of Open Office), also a quicker processor for other functions. I so miss TFF. Thanks, Ken.

  2. You could try running TenFourFox under Rosetta, but I suspect you will find it unsatisfactory; it's not really tested with it and there have been some recurrent issues. Some people do make it work, though, and perhaps they can share their "tips."

    That said, I have a standing rule that I don't maintain software I don't personally use. A few people have expressed interest in working on an Intel TenFourFox to me but nothing has really materialized. It would mostly require undoing the AltiVec and PPC JavaScript acceleration and using the built-in SSE2/3 and x86 code instead, so it would be non-trivial, but it would not require a massive amount of work since the rest of the changes for 10.4 will work presumably both on PPC and x86.

    However, why use Tiger on Intel? Snow Leopard will still run PowerPC software, is faster than Tiger on Intel, still gets some modicum of security updates and will still run the "real" Firefox. Snow Leopard DVDs aren't hard to find on the used market; Apple might even sell you one if you call AppleCare and ask, since you can't use the Mac App Store without it.

  3. Thanks, I see some of your reply but I think some is cutoff. If someone manages to accomplish this feat, shall that information be available on this blog or is there another site that I can bookmark to keep on checking for an Intel version of TFF? Many thanks, Ken.

    1. Thanks, just saw the other part of your reply. I am quite happy with Tiger, the drivers for my printer, scanner work perfectly, Tiger just flies on my iMac Core Duo (maxes out at 2 gigs of ram). Since I don't, nor shall I ever use an iPad, iPhone or iPod, the newer versions of Mac OSX are irrelevant, my setup is optimal.

  4. Replies
    1. Thanks, I'll check back regularly.

    2. I saw somewhere that TFF 8.0b1 works with an Intel iMac running Tiger so I got the G4/7450 version, works great, only version that does for me so I will use it until you create an Intel version of TFF. Nice to have TFF again. Ken.

  5. Will "slimming" TFF speed it up? Currently, Xslimmer won't slim TFF. Maybe we can influence that, if you think it'll help.

    Seems to help my FF speed for sure.

  6. Xslimmer only helps with universal binaries, because it removes the architecture not in use on the target system. TenFourFox is PowerPC-only, and only has one specific processor version in each release to boot.


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