On Wed, Oct 24, 2012 at 09:36:54PM +0200, Mike Hommey wrote: > With that replayed workload, I can see two main things: > - The amount of resident memory used by jemalloc 3 is greater than that > of mozjemalloc after freeing big parts of what was allocated (in > Firefox, after closing all tabs, waiting for a settle, and forcing GC). > This is most likely due to different allocation patterns leading to > some kind of fragmentation after freeing part of the allocated memory. > See http://i.imgur.com/fQKi4.png for a graphical representation of > what happens to the RSS value at the different checkpoints during the > Firefox workload. > - The amount of mmap()ed memory is dangerously increasing during the > workload. It almost (but not quite) looks like jemalloc don't reuse > pages it purged. See http://i.imgur.com/klfJv.png ; VmData is > essentially the sum of all anonymous ranges of memory in the process. > Such an increase in VmData means we'd eventually exhaust the 32-bits > address space on 32-bits OSes, even though the resident memory usage > is pretty low.
FWIW, both jemalloc 2.0.0 and 1.0.3 have the same behaviour as jemalloc 3, both for VmRSS and VmData. Mike _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
