Both 32-bit and 64-bit versions are being produced on all supported desktop platforms (Windows/Mac/Linux), with the exceptions that Windows 64-bit builds are only produced once a day rather than upon every checkin, and Mac builds are packaged as universal binaries where the 64-bit part requires Snow Leopard.

Running plugins out-of-process allows us to avoid the "plugin is for the wrong architecture" problem, at least in theory.

Firefox's JS engine now has three execution modes: interpreter (all platforms), tracing jit (several platforms), method jit aka "jaegermonkey" (x86, x86-64, ARM). On x86 you're probably using all three. On less popular platforms, it uses only the interpreter, which is slower but still works. And even the interpreter has gotten faster as part of the overall performance effort.

Why would an implementation that doesn't give away sensitive information be slow?

It would have to run the pointer through a one-way hash. Or store extra information for each object. Either way, there's a cost to generating and storing the hash code, which seems silly when you're going to stick it right into a normal hash table (which isn't exactly the fastest data structure in existence).

I don't understand why buckets make the code slow, leaky, or difficult to test.

Slow because the JavaScript code needs to do at least one comparison and branch on every lookup. (This is in addition to the native comparison and branch done by the native hash table!)

Leaky because the bucket has to hold onto the object (which is ok in some situations but not in others).

Difficult to test because usually the first item in the bucket will be the one you want, but sometimes it won't.

I also don't understand why a GC would have to keep extra information for an object whose hash code method was called.

A moving garbage collector would need to keep extra information around, because a hash-of-a-pointer changes when the object's location changes.

Are you ctrl+clicking a bunch of bookmarks? Try putting them in a folder and ctrl+clicking the folder to open them all in one click. Less clicking, more waiting for the browser to catch up!

If you run Kraken in Firefox and Safari, and then compare the results of the subtests (by copying and pasting a URL), you'll see that Firefox does better at some of the subtests and Safari does better at others. So in one sense, Mozilla has done exactly that.

If you have a loop consisting of creating divs and measuring their heights, you're doing it wrong. Of course forcing the browser to run its layout algorithm repeatedly is going to be slow.

If you're only doing it once, why do you care if it takes a few milliseconds?

How are you displaying your tree and grid? Creating a large DOM tree consisting of HTML table elements? Programmatically drawing to a canvas?

However you're doing it, you should ask Boris Zbarsky (bz) to profile it. He'll probably tell you exactly what you're doing wrong (forcing/causing the browser to do more work than really needed), and then immediately post a patch to Firefox to make it 30% faster anyway.

What you're really asking for is a way to keep tables of object-to-value.

One way a language can accomplish that, as you suggested, is for the language to supply a "hash code" function and then using the language's string-to-value hashes. But a "hash code" function has many problems. A moving garbage collector has to keep extra information around, at least for objects whose hash code has been retrieved. Any implementation that doesn't give away sensitive information (including pointers) is likely to be slow. More subtly, any implementation that prevents hash-key collisions will violate GC confidentiality. So the "hash code" function has to allow collisions, which means your object-to-value map (build on top of hashkey) has to use buckets, which make your code slow, leaky, and difficult to test.

A more straightforward solution is for the language to provide an object-to-value table type. I think this will be part of ES6 as WeakMap. Which, by the way, has excellent GC semantics.

The option is available. Right-click a toolbar and uncheck "Tabs on top".

The JaegerMonkey team understands why it's currently slower on 64-bit than on 32-bit. One reason is that the larger pointers on 64-bit systems don't play well with the value representation. If that can be fixed, perhaps by using a different value representation in 64-bit versions, it might end up faster on 64-bit than on 32-bit.

They're working on speeding up the 64-bit version. They have to, because of the plan to ship Firefox 4 as a 64-bit application for Mac OS X 10.6 ;)

(Btw, arewefastyet.com shows speeds of naked JavaScript engines, which are usually slightly faster than JavaScript engines inside web browsers.)

The Bugzilla entry is now public.

I think the markup-parsing part of the HTML5 spec is reasonably stable. Firefox is the first browser to implement the algorithm, so Firefox may have useful feedback for the spec.

Don't worry, we're planning to make many of the changes customizable. For example, you'll be able to put the tab bar above the address bar or below it. And we're not copying chrome pixel for pixel.

Why are you using this argument to support H.264 rather than, say, Theora? Currently, more users have support for Theora than H.264 (in the HTML5 video tag), because Firefox's marketshare is twice that of Chrome and Safari combined.

Flash includes an H.264 decoder, so moving from Flash to plain H.264 would be an improvement. Whether we want "the perfect to be the enemy of the good" is up for debate, of course.

Flash and H.264 are also "proprietary" in different ways (closed-source vs open-source with patents). Do both kinds of "proprietary" have the same negative consequences?