Rounding up huge allocations to page boundaries instead of chunks
ggp at mozilla.com
Thu Aug 21 14:52:07 PDT 2014
As part of our effort to move to jemalloc3 on Firefox, it would be interesting to upstream the
changes introduced into mozjemalloc in bug 683597 . Basically, we've observed that, at least
on Linux and OSX, the operating system will commit pages lazily when they're written to (as opposed
to when they're mapped by jemalloc). This distorts the allocation stats for huge allocations, as
they are rounded up to chunk boundaries.
For a concrete example, a huge allocation of size 1 chunk + 1 byte will cause jemalloc to map 2
chunks, but the application will only ever physically use 1 chunk + 1 page. I haven't found any
stats on jemalloc3 that reflect this smaller memory footprint; as far as I can see, all of the
available stats.* metrics report multiples of the chunk size. There was some previous discussion
about this on this list a few years ago, but it didn't seem to move forward at the time .
Would you be interested in upstreaming such change? I took a shot at adapting the old patch on that
bug to the current jemalloc3 repository , and it doesn't look like this would introduce too much
bookkeeping. I did seem to break some assumptions in other API functions (see the FIXME note on
huge_salloc), so it may be easier to just introduce a new statistic instead of tweaking the existing
size field in chunks. Thoughts?
More information about the jemalloc-discuss