Compartment data

From MozillaWiki
Jump to: navigation, search

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.


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


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


  • DOM nodes
  • strings
  • XBL bindings


  • buffers


  • 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.


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


  • reflow
  • style resolution
  • image decoding


  • parsing
  • tree construction
  • XBL compilation


  • buffer manipulation?
  • decompression?
  • SSL operations


  • IPC
  • sqlite
  • cycle collection