> How about making the JS engine use jemalloc instead of its own > allocator? Does anything actually rely on the arenas being independent > at the paging level?
My understanding, which may be wrong, is that the JS engine needs to be able to quickly map an object's address to a compartment. They do this by keeping a map (in the runtime?) of chunk addresses (1mb aligned) to compartments. Given an address, you can easily find its chunk (zero the low-order bits), and then it's a quick lookup to find its compartment. We could imagine shrinking chunks to 4kb, but that doesn't solve the fragmentation problem here; the fragmentation in "unused-arenas" is /within/ a page. (We also have a bunch of decommitted memory in these workers due to fragmentation between pages, but that's not a problem.) What you really need, I guess, is a moving GC. But I emphasize again that reducing the unused-arenas does not solve all of our problems, only the single largest. On Mon, Apr 22, 2013 at 11:05 AM, Mike Hommey <m...@glandium.org> wrote: > On Mon, Apr 22, 2013 at 10:53:40AM -0400, Justin Lebar wrote: >> > How about pre-compiling JS in JITed form? >> >> While significant, it seems that memory used for script source isn't >> the biggest offender. >> >> Full details are in the about:memory reports, >> >> http://people.mozilla.org/~jlebar/downloads/merged.json.xz >> http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz >> >> but here's a teaser. >> >> This is the wifi worker. I think "script-sources" is code. Note that >> fragmentation (unused-arenas) is way too high, but even despite this >> the worker uses too much memory. > > How about making the JS engine use jemalloc instead of its own > allocator? Does anything actually rely on the arenas being independent > at the paging level? > > Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
