(For those of you who have looked at about:memory before, some of those entries may look unfamiliar, because I landed a patch to refine the JS memory reporters<\/a> late last week.)<\/p>\n There is work underway to reduce many of the entries in that snapshot.\u00a0 SpiderMonkey is on a diet.<\/p>\n Objects are the primary data structure used in JS programs;\u00a0 after all, it is an object-oriented language.\u00a0 Inside SpiderMonkey, each object is represented by a JSObject, which holds basic information, and possibly a slots array, which holds the object’s properties. The memory consumption for all JSObjects is measured by the “gc-heap\/objects\/non-function” and “gc-heap\/objects\/function” entries in about:memory, and the slots arrays are measured by the “object-slots” entries.<\/p>\n The size of a non-function JSObject is currently 40 bytes on 32-bit platforms and 72 bytes on 64-bit platforms.\u00a0 Brian Hackett is working<\/a> to reduce that to 16 bytes and 32 bytes respectively<\/a>. Function JSObjects are a little larger, being (internally) a sub-class of JSObject called JSFunction.\u00a0 JSFunctions will therefore benefit from the shrinking of JSObject, and Brian is slimming down the function-specific parts<\/a> as well.\u00a0 In fact, these changes are complete in the JaegerMonkey repository<\/a>, and will likely be merged into mozilla-central early in the Firefox 11 development period.<\/p>\n As for the slots arrays, they are currently arrays of “fatvals” A fatval is a 64-bit internal representation that can hold any JS value — number, object, string, whatever.\u00a0 (See here<\/a> for details, scroll down to “Mozilla\u2019s New JavaScript Value Representation”;\u00a0 the original blog entry is apparently no longer available).\u00a0 64-bits per entry is overkill if you know, for example, that you have an array full entirely of integers that could fit into 32 bits.\u00a0 Luke Wagner and Brian Hackett have been discussing a specialized representation<\/a> to take advantage of such cases.\u00a0 Variations on this idea have been tried twice<\/a> before<\/a> and failed, but perhaps SpiderMonkey’s new type inference support will provide the right infrastructure for it to happen.<\/p>\n There are a number of data structures within SpiderMonkey dedicated to making object property accesses fast.\u00a0 The most important of these are Shapes.\u00a0 Each Shape corresponds to a particular property that is present in one or more JS objects.\u00a0 Furthermore, Shapes are linked into linear sequences called “shape lineages”, which describe object layouts.\u00a0 Some shape lineages are shared and live in “property trees”.\u00a0 Other shape lineages are unshared and belong to a single JS object;\u00a0 these are “in dictionary mode”.<\/p>\n The “shapes\/tree” and “shapes\/dict” entries in about:memory measure the memory consumption for all Shapes.\u00a0 Shapes of both kinds are the same size;\u00a0 currently they are 40 bytes on 32-bit platforms and 64 bytes on 64-bit platforms.\u00a0 But Brian Hackett has also been taking a hatchet to Shape, reducing them to 24 bytes and 40 bytes<\/a> respectively.\u00a0 This has required the creation of a new auxiliary BaseShape type, but there should be many fewer BaseShapes than there are Shapes.\u00a0 This change will also increase the number of Shapes, but should result in a space saving overall.<\/p>\n SpiderMonkey often has to search shape lineages, and for lineages that are hot it creates an auxiliary hash table, called a “property table”, that makes lookups faster.\u00a0 The “shapes-extra\/tree-tables” and “shapes-extra\/dict-tables” entries in about:memory measure these tables.\u00a0 Last Friday I landed a patch that avoids building these tables if they only have a few items in them<\/a>;\u00a0 in that case a linear search is just as good.\u00a0 This reduced the amount of memory consumed by property tables by about 20%.<\/p>\n I mentioned that many Shapes are in property trees.\u00a0 These are N-ary trees, but most Shapes in them have zero or one child;\u00a0 only a small fraction have more than that, but the maximum N can be hundreds or even thousands.\u00a0 So there’s a long-standing space optimization where each shape contains (via a union) a single Shape pointer which is used if it has zero or one child.\u00a0 But if the number of children increases to 2 or more, this is changed into a pointer to a hash table, which contains pointers to the N children.\u00a0 Until recently, if a Shape had a child deleted and that reduced the number of children from 2 to 1, it wouldn’t be converted from the hash form back to the single-pointer.\u00a0 I changed this<\/a> last Friday.\u00a0 I also reduced the minimum size of these hash tables<\/a> from 16 to 4, which saves a lot of space because most of them only have 2 or 3 entries.\u00a0 These two changes together reduced the size of the “shapes-extra\/tree-shape-kids” entry in about:memory by roughly 30–50%.<\/p>\n Internally, a JSScript represents (more or less) the code of a JS function, including things like the internal bytecode that SpiderMonkey generates for it.\u00a0 The memory used by JSScripts is measured by the “gc-heap\/scripts” and “script-data” entries in about:memory.<\/p>\n Luke Wagner did some measurements recently that showed that most (70–80%) JSScripts created in the browser are never run<\/a>.\u00a0 In hindsight, this isn’t so surprising — many websites load libraries like jQuery but only use a fraction of the functions in those libraries.\u00a0 It wouldn’t be easy, but if SpiderMonkey could be changed to generate bytecode for scripts lazily, it could reduce “script-data” memory usage by 60–70%, as well as shaving non-trivial amounts of time when rendering pages.<\/p>\n TraceMonkey is SpiderMonkey’s original JIT compiler, which was introduced in Firefox 3.5.\u00a0 Its memory consumption is measured by the “tjit-*” entries in about:memory.<\/p>\n With the improvements that type inference made to JaegerMonkey, TraceMonkey simply isn’t needed any more.\u00a0 Furthermore, it’s a big hairball that few if any JS team members will be sad to say goodbye to.\u00a0 (js\/src\/jstracer.cpp alone is over 17,000 lines and over half a megabyte of code!)<\/p>\n TraceMonkey was turned off for web content JS code when type inference landed.\u00a0 And then it was turned off for chrome code<\/a>.\u00a0 And now it is not even built by default<\/a>.\u00a0 (The about:memory snapshot above was from a build just before it was turned off.)\u00a0 And it will be removed entirely<\/a> early in the Firefox 11 development period.<\/p>\n As well as saving memory for trace JIT code and data (including the wasteful ballast hack<\/a> required to avoid OOM crashes in Nanojit, ugh), removing all that code will significantly shrink the size of Firefox’s code.\u00a0 David Anderson told me the binary of the standalone JS shell is about 0.5MB smaller with the trace JIT removed.<\/p>\n JaegerMonkey is SpiderMonkey’s second JIT compiler, which was introduced in Firefox 4.0.\u00a0 Its memory consumption is measured by the “mjit-code\/*” and “mjit-data” entries in about:memory.<\/p>\n JaegerMonkey generates a lot of code.\u00a0 This situation will hopefully improve with the introduction of IonMonkey<\/a>, which is SpiderMonkey’s third JIT compiler.\u00a0 IonMonkey is still in early development and won’t be integrated for some time, but it should generate code that is not only much faster, but much smaller.<\/p>\n There is a great deal of work being done on the JS garbage collector, by Bill McCloskey, Chris Leary, Terrence Cole, and others.\u00a0 I’ll just point out two long-term goals that should reduce memory consumption significantly.<\/p>\n First, the JS heap currently has a great deal of wasted space due to fragmentation, i.e. intermingling of used and unused memory.\u00a0 Once moving GC<\/a> — i.e. the ability to move things on the heap — is implemented, it will pave the way for a compacting GC, which is one that can move live things that are intermingled with unused memory into contiguous chunks of memory.\u00a0 This is a challenging goal, especially given Firefox’s high level of interaction between JS and C++ code (because moving C++ objects is not feasible), but one that could result in very large savings, greatly reducing the “gc-heap\/arena\/unused” and “gc-heap-chunk-*-unused” measurements in about:memory.<\/p>\n![\"about:memory](\"http:\/\/blog.mozilla.org\/nnethercote\/files\/2011\/10\/js-compartment.png\" "\\"js-compartment\\"")
<\/a><\/p>\nObjects<\/h3>\n
Shapes<\/h3>\n
Scripts<\/h3>\n
Trace JIT<\/h3>\n
Method JIT<\/h3>\n
GC HEAP<\/h3>\n