The GCMarker starts off taking 256KB and if I run gregor-wagner.com/tmp/mem it gets up to 2.8MB. This first patch just adds SizeOf{In,Ex}cludingThis to Vector.

Pretty simple. Bill, does the MarkStack ever shrink? If not, it's the kind of thing that hurts us w.r.t. bug 668809.

I just worked out the following: this patch measures only JSRuntime::gcMarker, which is the main marker and has a 256KB stack. There are other short-lived GCMarker objects as well that start with 0KB stacks. This patch doesn't measure them.

Comment on attachment 599479 [details] [diff] [review] add js/runtime/gc-marker Review of attachment 599479 [details] [diff] [review]: ----------------------------------------------------------------- This looks fine aside from skipping the per-compartment barrier markers. In the not-too-distant future, I'd like to eliminate those. They're not necessary now that we have a single-threaded runtime. Also, I'll try to put something together to reset the mark stack size when the GC is over.

https://hg.mozilla.org/integration/mozilla-inbound/rev/da193f5b526b https://hg.mozilla.org/integration/mozilla-inbound/rev/a7255af10a2a

Backed out both (because I wasn't likely to figure out which) in https://hg.mozilla.org/integration/mozilla-inbound/rev/85715b21f80e - both Mac debug builds agreed that they should assert about "The two measurements of 'explicit' memory usage don't match: 'explicitNonHeapMultiSize == explicitNonHeapMultiSize2'"

Second landing attempt: https://hg.mozilla.org/integration/mozilla-inbound/rev/89c46aa25a14 https://hg.mozilla.org/integration/mozilla-inbound/rev/dbe3f8bad3b5

https://hg.mozilla.org/mozilla-central/rev/89c46aa25a14 https://hg.mozilla.org/mozilla-central/rev/dbe3f8bad3b5

A tiny follow-up to fix a runtime warning: https://hg.mozilla.org/integration/mozilla-inbound/rev/a0f77fee1568