Closed Bug 675216 Opened 8 years ago Closed 8 years ago

Update about:memory's description of heap-committed

Categories

(Toolkit :: about:memory, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

(Whiteboard: [inbound])

Attachments

(1 file)

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.

[1] Bug 671702 comment 34
[2] 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
Attached patch Patch v1Splinter Review
Attachment #550785 - Flags: review?(nnethercote)
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
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/b0d6e197c741
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: in-testsuite-
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.
Blocks: 684592
(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.