Closed Bug 625305 (about:compartments) Opened 13 years ago Closed 13 years ago

about:compartments

Categories

(Core :: XPConnect, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: shaver, Assigned: n.nethercote)

References

()

Details

(Keywords: memory-footprint, Whiteboard: [MemShrink:P2])

Attachments

(3 files, 5 obsolete files)

Attached patch about:compartments v1 (obsolete) — Splinter Review
I present a first cut of about:compartments, which tells you how much method JIT memory and how many gcBytes are being used by each current compartment.  Lots more to do (JS heap accounting, figuring out what to do with the DOM and layout and imglib memory, trace-jit stuff).  Dunno if it's interesting for FF4 -- new code doesn't run unless you go to about:compartments, by risk-minimization design.

I don't want to talk about how long it took to write those ~500 new lines of code.
Attached image screenshot (obsolete) —
You don't have to tell me it's ugly.
it's beautiful.
did a quick skim through the code. This looks pretty sweet and could give us the basis for some real memory monitors(!).

There are some empty method stubs in here, and presumably a bit of work to do before it's ready for a blast through the try servers, but I'm pretty eager to get this kind of support into the platform so we can start creating memory monitors.

nice work!
I'm also curious if there are any platform limitations on this. Will this run everywhere? Just Windows?
Severity: normal → enhancement
OS: Windows 7 → Windows XP
Updated to include more stuff, and properly constrain to a compartment.
Assignee: nobody → shaver
Attachment #503431 - Attachment is obsolete: true
Severity: enhancement → normal
Rob: it'll run everywhere, it's all platform-agnostic code.
Attached image updated screenshot
I took out gcLastBytes after I took the screenshot, and it's shrunk down a bit to show more interesting data -- 12MB of mjit code for facebook/plugins/recommendations!
Attachment #503432 - Attachment is obsolete: true
Alias: about:compartments
Next up: trace JIT memory, and then I move onto DOM structures!
Attachment #509985 - Attachment is obsolete: true
tjit-code-net doesn't include everything I want it to yet, because some of the allocators don't expose their balance through public-enough interfaces.

http://webkit.org/perf/sunspider-0.9.1/sunspider-0.9.1/driver.html {
  "mjit-code-net": 1786695,
  "tjit-code-net": 52816,
  "script-count": 865,
  "script-count-mjit": 367,
  "script-count-tjit": 4,
  "string-count": 13,
  "string-data": 140,
  "object-count": 9602,
  "function-count": 8745,
  "off-heap-object-data": 210968,
  "gc-bytes": 39051264,
  "gc-bytes-objects": 18595840,
  "gc-bytes-functions": 6639616,
  "gc-bytes-xml": 0,
  "gc-bytes-strings": 13815808
}
Attachment #510054 - Attachment is obsolete: true
This patch overlaps with the ones in this bug. It tracks net and gross usage, as well as cumulative usage (discounting frees). Cumulative numbers seems to be somewhat more stable than the current total, so it might be useful for tuning.

Eventually I'd like to integrate this stuff with the other patches here. For now I'm posting it so that dvander can maybe use it.
I reckon ultimately about:memory and about:compartments should be merged, though this wouldn't have to happen immediately.  It'd also be nice if the measurements were less ad hoc -- for example, about:memory's "mapped"/"in use" measurements are just for the heap and exclude executable memory allocated by the JITs.  And it'd be nice if all the sub-listings added up to the totals in an understandable fashion.

As for this bug:  something I'd love to see in about:compartments would be a "Do a GC" button.  Actually, you could have one per compartment to force a compartment GC, plus one to force a global GC.  This would be a huge help for a bug like bug 630932 where I was trying to work out if there's a leak, but I could never quite tell if there was a GC pending that would get rid of a lot of junk.  Would that be difficult?  

(Hmm, "javascript: gc()" suffices?  Though that's presumably a global GC?  Can a compartment GC be done that way?  Also, can the cycle collector be manually triggered?)
There is garbageCollect in nsIDOMWindowUtils.
the "includeInTotal" and units will combine to give us the totals you want.  I may come up with a prefix model too, to make some of the hierarchy more straightforward as well.  Probably not until this weekend, though, and I'm not sure this'll make it in 4.
(In reply to comment #12)
> I reckon ultimately about:memory and about:compartments should be merged,

I blogged about this and some follow-on thoughts:  http://blog.mozilla.com/nnethercote/2011/02/09/a-vision-for-better-memory-profiling-with-aboutmemory/
Comment on attachment 510064 [details] [diff] [review]
classify heap kinds, add tjit data, classify scripts

>+    size_t grossSize() {
>+        size_t gross = 0;
>+        for (ExecutablePool **ep = m_smallAllocationPools.begin();
>+             ep != m_smallAllocationPools.end();
>+             ++ep) {
>+            gross += (*ep)->grossAllocationSize();
>+        }
>+        return gross;
>+    }

Oh, this is insufficient.  m_smallAllocationPools holds up to four ExecutablePools;  it does this just to minimize fragmentation (see bug 616310).  If more than four pools have been created, the ExecutableAllocator will have lost track of them.  (References to the pools will be stored in other places like JITScripts and IC structures so they haven't been lost altogether.)

So ExecutableAllocator will need to have a vector added to it that hang onto all of the pools it has created.  I was planning to do this anyway, because I want to get rid of the reference counting of executable pools and instead just deallocate them all when the compartment is destroyed, and that requires exactly this vector.
yeah, I know that's wrong.  I don't use it anywhere yet, IIRC.  I was thinking about fixing it to count correctly, and then I saw your cleanup bug, so I figured I'd just wait it out. :)
Will this help identify leaks?  Eg. if I open foo.com and bar.com in two tabs, then close the bar.com tab, if the bar.com compartment stays around that means there's a leak of some kind?
(In reply to comment #15)
Maybe not merge about:memory and about:compartment memory information?
The compartment resource presentation has significant user relevance and could potentially ascend to be a menu selection and therefore its display requirements may become different -- much more user friendly/interactive.

For now, would simple cross references suffice?  (see "about:compartments" ...)
This patch does a GC-style trace of the live heap.  But that has a couple of problems:

- you can overflow the stack

- it only counts live objects

Bug 571249 will add code to do traversals of the GC arenas (ie. both live and dead objects).  That will be done on a global basis, but will provide a good bases for per-compartment traversals required for this bug.
Assignee: shaver → nnethercote
Depends on: 571249
Whiteboard: [MemShrink:P2]
I'm going to WONTFIX this in favour of bug 661474, which is my preferred way of presenting this information.  Parts of the code from Shaver's patch will live on in bug 666075, however.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.