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).