Main menu:

Site search



JS Newsletter 11/2-11/22

Update since last time (11/1):

Stuff that might affect you

We are moving to a model where JSRuntimes are single-threaded. That means if you want to use multiple threads, you’ll create separate runtimes. (Web workers do this in Firefox now.) This is going to help us make a lot of simplifications to the engine, and will be more robust than the current model.

In preparation for single-threaded runtimes, Luke landed a patch that asserts that a JSRuntime is used only from its ‘owner’ thread. If you get Assertion failure: rt->onOwnerThread(), it’s from using a runtime from multiple threads.

Luke is going to have a blog post that explains the changes and the new model in more detail in the near future.


I went to Velocity Europe and gave my “Know Your Engines” JS talk. As usual for such a trip, I was always fighting jet lag, but I saw and really enjoyed the talks on Amazon Silk, browser performance (Opera, Chrome, and Firefox), and performance guidelines for mobile web development. A week or so later I gave the same talk at LinkedIn to an audience that asked a lot of fun questions.

Not much has had to be updated since my original version of the talk, just because not too many big JS performance improvements have been shipped since June. Changes are coming soon, though: Chrome has landed incremental GC in the developer channel (labeled version 17; note: for me, Firefox got a better score on the particular benchmark linked there, but you can try it yourself), and we are getting close to landing it as well. With JM+TI coming in Firefox 9, and IonMonkey later on, we’ll have more advanced typed compilers out there, and we should get to learn more about what they really do in practice. The long-term question is whether all browsers will get similar compilers, so that web devs that want to reach all users can count on them.

GC Update

Bill McCloskey landed write barriers for incremental GC. That’s the first hard part of IGC, the part that makes it not crash all over the place. Bill is finishing up the incrementalization itself. The second hard part will be tuning: finding out how short the pauses can be dialed down and making sure pages that have GC pauses now actually do get incrementalized. This stuff is hard, and we don’t know how much tuning work there will be, but we’re currently targeting IGC landing for Firefox 11.

Terrence Cole landed a patch to mark unused GC arenas as decommitted. This means when a piece of GC memory (a 4k arena) becomes empty after a shrinking GC, the memory is no longer committed to Firefox, is no longer reported as allocated for the process, and can be immediately reused by the OS. (Previously, Firefox generally held on to these arenas.)

Other Stuff

Boris Zbarsky added a JS_GetElementIfPresent API to make things faster, specifically Array.prototype.Slice on NodeLists.

IonMonkey development continues. Marty finished a new ARM backend. Chris finished function inlining. The team is still finishing on-stack replacement and other infrastructure, so IM can’t run too many benchmarks yet or do anything interesting in a browser. But I think it will start running more benchmarks soon, so we’ll get to see how it’s doing on basic performance.

JM+TI is looking good and on track for shipping with Fx9, with nice speedups pretty much across the board.


Comment from Alexander
Time: November 24, 2011, 1:37 am

a lot of extensions are stain Firefox with their remains in RAM. I hope this will help, looking forward to see the landings.

Comment from ?
Time: November 25, 2011, 1:46 am

>and we are getting close to landing it as well
From outside, incremental GC in FF looks like vaporware. No comments or patches in the bug, no repository, nothing.