Hello, 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 [1]. 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 [2]. 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 [3], 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? 1- https://bugzilla.mozilla.org/show_bug.cgi?id=683597 2- http://www.canonware.com/pipermail/jemalloc-discuss/2012-April/000221.html 3- https://github.com/guilherme-pg/jemalloc/commit/9ca3ca5f92053f3e605f7b470ade6e53e8fa5160 -- Guilherme _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
