We want to know: - working set size on startup - working set sizes for some interesting GC-heavy applications - allocation rates for some interesting GC-heavy applications - M: average ratio of mark time to working set size - S: average ratio of sweep time to allocated heap size

first version

This is the sample output for a high-throughput page like http://29a.ch/2010/6/2/realtime-raytracing-in-javascript The current working-set approach gets stable after a very few GC calls but the actual memory requirement is enormous. We are allocating over 1000 chunks. live means live objects during the GC cycles means average cycles needed to mark an object finalized menas finalized object during GC run cycles means average cycles needed to finalize an object.

The output of running v8 vers5 in the browser

A microbenchmark for the shell.

The output of the microbenchmark shows that for a kind of "ideal" environment we need about 128 cycles to mark an object and 47 to finalize it. Note that even if we mark a full heap, we spend a lot of time iterating over full arenas. So the finalization phase, even if we don't finalize a single object, takes 50% of the time if we would finalize almost every object.

That's the right file for the microbenchmark.

An updated version. It extends the existing GCTimer options for each GC with: comp: number of compartments live: marked objects finalized: finalized objects Reason: What caused the GC AllSW: number of all scanned words on the stack ValSW: number of all stackwords that got marked (valid pointer)

Still a valid non-TM bug?

Let's keep this open. Some of the stuff in this bug must have landed in a different bug, but some of it didn't and it's still useful.