Closed Bug 675216 Opened 10 years ago Closed 10 years ago
Update about:memory's description of heap-committed
I keep telling people that it's not committed, non-shared, non-copy-on-write pages. At least, it appears that it can't be, because heap-committed is often many times larger than RSS, and I don't think we've swapped out 4/5 of Firefox in these examples [1, 2]. So what *does* heap-committed measure? We should figure this out.  Bug 671702 comment 34  Bug 671702 comment 49
Ah, I think I may have a guess here. Without DECOMMIT (so, on Linux) jemalloc madvise DONT_NEED's blocks instead of decommitting them. But those blocks aren't taking up any space in memory.
Component: jemalloc → about:memory
Product: Core → Toolkit
QA Contact: jemalloc → about.memory
Summary: Figure out what jemalloc's heap-committed number means → Update about:memory's description of heap-committed
Comment on attachment 550785 [details] [diff] [review] Patch v1 Review of attachment 550785 [details] [diff] [review]: ----------------------------------------------------------------- rs=me. At this point you understand this stuff much better than I do :)
Attachment #550785 - Flags: review?(nnethercote) → review+
backed out from mozilla-inbound for busting builds
Maemo is picky about a semicolon.
This push is healthier. Thanks for the quick backout, Dao! http://hg.mozilla.org/integration/mozilla-inbound/rev/b0d6e197c741
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
The description says that "heap-committed should equal heap-allocated + heap-unallocated". I am using current nightly on Windows Vista, and this is an example of my about:memory after some browsing: 78,900,180 B -- heap-allocated 86,630,400 B -- heap-committed 3,530,752 B -- heap-dirty 20,713,834 B -- heap-unallocated -> heap-committed != heap-allocated + heap-unallocated Why is that?
> Why is that? I'm not sure. The end of jemalloc_stats() says: (jemalloc.c) > #ifndef MALLOC_DECOMMIT > stats->committed = stats->mapped; > #endif so committed = mapped on Windows, where we define MALLOC_DECOMMIT. heap-allocated is stats.allocated, and heap-unallocated is stats.mapped - stats.allocated (nsMemoryReporterManager.cpp). So allocated + unallocated = mapped = committed. Weird...
(In reply to Justin Lebar [:jlebar] from comment #9) > Weird... Can you reproduce the problem? If so, do you want to file a new bug? You obviously know more about the details than I do.
(In reply to Christian Ascheberg from comment #10) > Can you reproduce the problem? If so, do you want to file a new bug? You > obviously know more about the details than I do. All fixed now in bug 684592. My mistake was in comment 9; I read #ifndef MALLOC_DECOMMIT as #ifdef!
You need to log in before you can comment on or make changes to this bug.