Main menu:

Site search

Categories

Archive

Mozilla JS Development Newsletter 11/30-12/06

This will be a short one: it’s been a fairly quiet week, with mostly fixes for crashes and other small bugs.

The one big landing was ObjShrink, by Brian Hackett, which took the size of a JS object down from about 48 bytes (on 32-bit platforms) to 16 bytes. ObjShrink also made shapes (an auxiliary data structure that records object property layouts) smaller. I tested ObjShrink in practice by comparing starting Firefox and loading TechCrunch on a Dec 2 nightly and a Dec 6 nightly. The memory usage for the TechCrunch tab went from 4.84MB to 4.02MB. Overall memory usage went from 51.8MB to 49.3MB–I noticed that the system compartment showed a big drop, presumably because the browser UI uses a lot of JS objects. That’s a 17% improvement in a JS-heavy tab and almost a 5% improvement overall, which is a huge memory win.

Jeff Walden landed some refactorings to the parser–we’re hoping to make it easier to hack on for doing ECMAScript Harmony work. For IonMonkey, Nicolas Pierron and Jan de Mooij added support for some more opcodes to the compiler so the team can run more benchmarks. Incremental GC is working on the larch branch, but Bill is still fixing bugs (I helped with one today too). RyanVM (Ryan VanderMeulen) has been cleaning up more tracejit leftovers. Finally, Hannes Verschore, one of our 2011 summer interns, fixed a 3-year old bug that caused incorrect error messages with certain usages of let.

[Update: I made slight corrections to the percentage wins shown in the first draft. I had originally written 20% and 4%.]

Comments

Comment from gonchuki
Time: December 6, 2011, 7:29 pm

awesome! does that mean the ObjShrink is complete? any other interesting numbers for JS heavy sites like GMail or Facebook?

Comment from Ed
Time: December 6, 2011, 7:55 pm

The ObjectShrink Wins Number are much smaller then i thought. The JS memory of 20% was inline, but i dont understand how it was only a 5% overall reduction.

Comment from azakai
Time: December 6, 2011, 8:11 pm

Ed, I guess JS objects are not the majority of the browser’s memory usage. Aside from JS objects and shapes, there is JIT code, strings, etc. which remain the same as before. And, JS is just one thing in the browser, there is also native code and data structures, image data, etc.

In any case, the bottom line is that a 5% reduction in overall size is a very impressive achievement! That’s a lot of megabytes being saved.

Comment from Boris
Time: December 6, 2011, 8:37 pm

Ed, the testcase was loading a single tab. At that point, for dmandelin’s numbers, you have 5MB of memory being used by the tab and 47MB used by things like all the Gecko code that’s located in memory, the browser UI, etc.

Reducing the size of JS objects does not reduce the amount of space that Gecko code takes in memory, so no matter what objshrink did that 47MB wasn’t going to get smaller.

Now as you have more pages loaded and as the pages are more JS-intensive, the relative fraction of that 47MB in overall browser memory usage shrinks, of course. So on bigger workloads objshrink wins more.

Comment from Erik Corry
Time: December 7, 2011, 4:03 am

So how much memory does it now take to run the stress test from http://blog.chromium.org/2011/11/game-changer-for-interactive.html ? For 60 seconds vs. 600 seconds?

Comment from Caspy7
Time: December 7, 2011, 7:24 am

Thanks so much for the update! This is great stuff.

I’m wondering if there is a already standardized testcase, like top 10 or 15 sites, for comparison.
Top *JS intensive* sites would be handy too.
Just as an example one could choose some big JS consumers (but not oddly uncommon) sites and do a comparison to show the difference.

Comment from pd
Time: December 11, 2011, 7:02 am

Congrats to Brian Hackett and all involved. It warms the heart to read of such great work focusing with a fine-tooth comb on memory and JS perf issues.