699721 - Include JSCompartment::typeLifoAlloc in TI memory reporting

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

DMD just told me this while loading Gmail:

Unreported: 614,400 (cumulative: 13,347,230) bytes in 150 heap block(s) in record 11 of 16459: 
 Requested bytes unreported: 614,400 / 614,400 
 Slop      bytes unreported: 0 / 0
   at 0x402A063: malloc (vg_replace_malloc.c:263)
   by 0x809229D: js_malloc (Utility.h:166)
   by 0x80922D4: js::detail::BumpChunk::new_(unsigned long) (LifoAlloc.cpp:54)
   by 0x809275E: js::LifoAlloc::getOrCreateChunk(unsigned long) (LifoAlloc.cpp:180)
   by 0x81AC7C7: js::analyze::ScriptAnalysis::analyzeBytecode(JSContext*) (LifoAlloc.h:230)
   by 0x7EEE7B8: JSScript::makeAnalysis(JSContext*) (jsinfer.cpp:5507)
   by 0x7EF306A: JSScript::ensureRanAnalysis(JSContext*, JSFunction*, JSObject*) (jsinferinlines.h:1270)
   by 0x7F21EDF: js::types::TypeMonitorCall(JSContext*, js::CallArgs const&, bool) (jsinferinlines.h:327)

There was another 300KB+ in similar records.

Looks like JSCompartment::typeLifoAlloc isn't accounted for.  Should be easy to add.  It should probably go under "analysis-temporary".

Comment 1

[Brian Hackett [Laid off!]]

All analysis-temporary measures is the size of typeLifoAlloc, is that computation being done incorrectly?

Comment 2

[Nicholas Nethercote [inactive]]

Hmm, I'll have to investigate more.  Some JS code runs between the analysis-temporary recorder running and DMD doing its final analysis, that might be the cause, though 600KB seems like a lot.

Comment 3

[Nicholas Nethercote [inactive]]

Ok, this turned out to be bone-headedness on my part:  in my private version of Firefox that has DMD annotations, I failed to annotate the TI reporters.  Duh.