Per-compartment reporting

We want to track a bunch of things on a per-compartment basis, to help isolate site-and-chrome resource usage, including memory and CPU. These are their stories.

Bug 625305 tracks at least the initial implementation (paused until after FF4).

Memory usage

For many of these things, we want to track gross and net; gross should contribute to the compartment's total use.

JS

• method JIT code (except ICs)
• interpreter code
• trace JIT code
• GC heap
• off-GC-heap object data (dslots)
• shapes
• strings

Layout

• image data (compressed and uncompressed)
• layer memory
• OS backing stores?
• frames (net and gross/pool)
• string contents?
• style rules

Content

• DOM nodes
• strings
• XBL bindings

Network

• buffers

XPCOM/system

• service hashtables
• IPC buffers and protocols
• sqlite
• prefs?
• cycle collector structures

CPU Usage

It's probably going to be hard to distinguish some of these efficiently, so DOM-tree modification and style resolution that happens due to JS (eagerly or lazily) may have to be accounted under a big "DHTML" bucket or something.

JS

• Parse and bytecode-compile
• trace compilation
• mjit compilation
• main-thread garbage collection
• script execution (of all types, interp/mjit/tjit)
• type inference

Layout

• reflow
• style resolution
• image decoding

Content

• parsing
• tree construction
• XBL compilation

Networking

• buffer manipulation?
• decompression?
• SSL operations

XPCOM/System

• IPC
• sqlite
• cycle collection