Last Comment Bug 696690 - Memory reporter for the startup cache
: Memory reporter for the startup cache
Status: RESOLVED FIXED
[MemShrink]
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla10
Assigned To: Nicholas Nethercote [:njn]
:
: Nathan Froyd [:froydnj]
Mentors:
Depends on: DMD
Blocks: 697335
  Show dependency treegraph
 
Reported: 2011-10-23 18:17 PDT by Nicholas Nethercote [:njn]
Modified: 2011-10-26 06:12 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (7.78 KB, patch)
2011-10-23 20:09 PDT, Nicholas Nethercote [:njn]
taras.mozilla: review-
Details | Diff | Splinter Review
patch, v2 (7.93 KB, patch)
2011-10-24 17:13 PDT, Nicholas Nethercote [:njn]
taras.mozilla: review+
Details | Diff | Splinter Review

Description Nicholas Nethercote [:njn] 2011-10-23 18:17:41 PDT
The startup cache should have one or more memory reporters.  In particular, I saw this once I extended DMD to track mmap/munmap:

==1586== Unreported: 958,464 (cumulative: 535,731,680) bytes in 1 mapped block(s) in record 31 of 15105:
==1586==  Requested bytes unreported: 958,464 / 958,464
==1586==  Slop      bytes unreported: 0 / 0
==1586==    at 0x5228D6A: mmap (syscall-template.S:82)
==1586==    by 0x4089FC1: _MD_MemMap (unix.c:3612)
==1586==    by 0x4066BF3: PR_MemMap (prmmap.c:82)
==1586==    by 0x6855720: nsZipHandle::Init(nsILocalFile*, nsZipHandle**) (nsZipArchive.cpp:194)
==1586==    by 0x6855E83: nsZipArchive::OpenArchive(nsIFile*) (nsZipArchive.cpp:296) 
==1586==    by 0x6865D63: mozilla::scache::StartupCache::LoadArchive() (StartupCache.cpp:225)
==1586==    by 0x6865C36: mozilla::scache::StartupCache::Init() (StartupCache.cpp:201)
==1586==    by 0x686555F: mozilla::scache::StartupCache::InitSingleton() (StartupCache.cpp:111)

That's big enough to be worth tracking.  We've been using the term "dark matter" to refer to memory covered by about:memory's "heap-unclassified" entry, which is a "known unknown".  In contrast, this could be called "darker matter" -- it's not included in "heap-unclassified" and so is part of an "unknown unknown".

(BTW: as far as I can tell the above allocation lives for the life of the browser.  Is this intended?  The "startup cache" sounds like something that might be unloadable after a while, but I'm just guessing really.)

I also saw the following, which isn't terribly big:

==1586== Unreported: 126,976 (cumulative: 548,427,584) bytes in 2 heap block(s) in record 79 of 15105:
==1586==  Requested bytes unreported: 122,444 / 122,444
==1586==  Slop      bytes unreported: 4,532 / 4,532
==1586==    at 0x402A063: malloc (vg_replace_malloc.c:263) 
==1586==    by 0x403BFFA: moz_xmalloc (mozalloc.cpp:103)
==1586==    by 0x68660B8: mozilla::scache::StartupCache::PutBuffer(char const*, char const*, unsigned int) (mozalloc.h:242)
==1586==    by 0x74A4088: WriteCachedScript(mozilla::scache::StartupCache*, nsACString_internal&, JSContext*, JSScript*) (moz
JSLoaderUtils.cpp:189)
==1586==    by 0x749F1D5: mozJSComponentLoader::GlobalForLocation(nsILocalFile*, nsIURI*, JSObject**, char**, JS::Value*) (mo
zJSComponentLoader.cpp:1003) 
==1586==    by 0x749D77F: mozJSComponentLoader::LoadModuleImpl(nsILocalFile*, nsAString_internal&, nsIURI*) (mozJSComponentLo
ader.cpp:607)
==1586==    by 0x749D3A4: mozJSComponentLoader::LoadModule(nsILocalFile*) (mozJSComponentLoader.cpp:547)
==1586==    by 0x7A42B50: nsComponentManagerImpl::KnownModule::Load() (nsComponentManager.cpp:951)

I've seen other startup cache entries in DMD's output on occasion, but they tend to be short-lived.
Comment 1 Nicholas Nethercote [:njn] 2011-10-23 20:09:46 PDT
Created attachment 568997 [details] [diff] [review]
patch

This patch adds a "startup-cache" reporter which measures the size of the file mapped into memory.

We could also measure StartupCache::mTable and the strings that it points to, but I haven't done that.  Maybe in a follow-up bug.
Comment 2 (dormant account) 2011-10-24 11:27:38 PDT
Nicholas,
This mmap() memory usage is similar to memory overhead of libraries so shouldn't this be resident/startup-cache rather than explicit(and we could also read proc/smaps to have a more exact figure)?

The second one is indeed explicit and worth tracking.
Comment 3 (dormant account) 2011-10-24 11:29:08 PDT
Comment on attachment 568997 [details] [diff] [review]
patch

startup cache mapping is mainly accessed on startup, OS should page most of it out once browser is started up. Reporting that as an explicit allocation is misleading
Comment 4 Justin Lebar (not reading bugmail) 2011-10-24 11:34:51 PDT
> startup cache mapping is mainly accessed on startup, OS should page most of it out once browser is 
> started up.

It would be great if we could test whether this is true.  It looks like the file being mapped should be named "startupCache", but I don't see that in about:memory's smaps breakdown.  What's the file called on Linux?

> This mmap() memory usage is similar to memory overhead of libraries so shouldn't this be 
> resident/startup-cache rather than explicit

We don't have a resident/ tree.
Comment 5 (dormant account) 2011-10-24 11:48:38 PDT
(In reply to Justin Lebar [:jlebar] from comment #4)
> > startup cache mapping is mainly accessed on startup, OS should page most of it out once browser is 
> > started up.
> 
> It would be great if we could test whether this is true.  It looks like the
> file being mapped should be named "startupCache", but I don't see that in
> about:memory's smaps breakdown.  What's the file called on Linux?

startupCache.4.little on 32bit, .8.little on 64. Note that startupCache is folded into the omnijar on PGO builds. 

I'm guessing about:memory doesn't track our mmap()ed zip files either.

> 
> > This mmap() memory usage is similar to memory overhead of libraries so shouldn't this be 
> > resident/startup-cache rather than explicit
> 
> We don't have a resident/ tree.

http://blog.mozilla.com/nnethercote/2011/09/07/memshrink-progress-week-12/ shows resident memory.
Comment 6 Justin Lebar (not reading bugmail) 2011-10-24 11:51:08 PDT
> http://blog.mozilla.com/nnethercote/2011/09/07/memshrink-progress-week-12/ shows resident memory.

That comes straight from smaps.
Comment 7 Justin Lebar (not reading bugmail) 2011-10-24 11:54:07 PDT
So I guess I should have said "we don't build a resident/ tree using memory reporters."  :)
Comment 8 (dormant account) 2011-10-24 11:57:53 PDT
(In reply to Justin Lebar [:jlebar] from comment #7)
> So I guess I should have said "we don't build a resident/ tree using memory
> reporters."  :)

The right fix is to show startup cache(and other mmaped files in the profile dir) under resident/
Comment 9 Justin Lebar (not reading bugmail) 2011-10-24 12:08:07 PDT
resident/ only exists on Linux, but startupcache exists elsewhere (?).  What do you propose we do outside Linux?

I just did a non-PGO release build, and I don't see omnijar or startupcache in my vsize or RSS breakdown.  Maybe we're interpreting these as anonymous mappings.  That would be lame.
Comment 10 (dormant account) 2011-10-24 12:17:18 PDT
(In reply to Justin Lebar [:jlebar] from comment #9)
> resident/ only exists on Linux, but startupcache exists elsewhere (?).  What
> do you propose we do outside Linux?
> 
> I just did a non-PGO release build, and I don't see omnijar or startupcache
> in my vsize or RSS breakdown.  Maybe we're interpreting these as anonymous
> mappings.  That would be lame.

no omnijar in dist/bin, you'll see omnijar if you make package and run from dist/firefox. Re outside of linux: same thing(ie nothing) as we do for library files(since their overhead is greater anyway).
Comment 11 Nicholas Nethercote [:njn] 2011-10-24 12:59:24 PDT
(In reply to Taras Glek (:taras) from comment #3)
> 
> startup cache mapping is mainly accessed on startup, OS should page most of
> it out once browser is started up. Reporting that as an explicit allocation
> is misleading

No.  I defined the term "explicit";  it's for all allocations directly done by Firefox, including all calls to malloc and mmap.

I do not want to ignore some allocations.  It's better to include the startup mapping.  Then it's possible to say "oh, that doesn't matter much because it's only accessed at startup".
Comment 12 Nicholas Nethercote [:njn] 2011-10-24 17:13:38 PDT
Created attachment 569239 [details] [diff] [review]
patch, v2

I talked with Taras on IRC, he's now happier about this being included under "explicit".  I updated the reporter's description, too.
Comment 13 Nicholas Nethercote [:njn] 2011-10-24 17:16:16 PDT
(In reply to Taras Glek (:taras) from comment #5)
> 
> I'm guessing about:memory doesn't track our mmap()ed zip files either.

Which files are they?  I didn't see any other significant mmap'd files in my DMD output, but there could be cases that I didn't see in that run.
Comment 14 (dormant account) 2011-10-24 17:20:07 PDT
Comment on attachment 569239 [details] [diff] [review]
patch, v2

> 
>+static PRInt64
>+GetStartupCacheSize()
>+{
>+    return mozilla::scache::StartupCache::GetSingleton()->SizeOfMapping();
>+}

Note this can fail if there is no profile(ProfLDS) dir.
Comment 15 (dormant account) 2011-10-24 17:40:23 PDT
(In reply to Nicholas Nethercote [:njn] from comment #13)
> (In reply to Taras Glek (:taras) from comment #5)
> > 
> > I'm guessing about:memory doesn't track our mmap()ed zip files either.
> 
> Which files are they?  I didn't see any other significant mmap'd files in my
> DMD output, but there could be cases that I didn't see in that run.

extensions are kept in zips + omni.jar in dist/firefox.
Comment 16 Nicholas Nethercote [:njn] 2011-10-24 17:55:01 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/a394d649cf90
Comment 17 Nicholas Nethercote [:njn] 2011-10-24 18:14:23 PDT
Bustage fix for Maemo:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c20d0c530997
Comment 18 Andrew McCreight [:mccr8] 2011-10-24 18:16:28 PDT
Man, that's the third time I've seen people have that exact same bustage on Maemo. (semicolon after a macro)
Comment 20 Daniel Cater 2011-10-26 06:12:15 PDT
(In reply to Taras Glek (:taras) from comment #15)
> (In reply to Nicholas Nethercote [:njn] from comment #13)
> > (In reply to Taras Glek (:taras) from comment #5)
> > > 
> > > I'm guessing about:memory doesn't track our mmap()ed zip files either.
> > 
> > Which files are they?  I didn't see any other significant mmap'd files in my
> > DMD output, but there could be cases that I didn't see in that run.
> 
> extensions are kept in zips + omni.jar in dist/firefox.

Is there a bug for this?

Note You need to log in before you can comment on or make changes to this bug.