Add js/runtime/gc-marker memory reporter

RESOLVED FIXED in mozilla13

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: njn, Assigned: njn)

Tracking

(Blocks: 1 bug)

unspecified
mozilla13
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink])

Attachments

(2 attachments)

(Assignee)

Description

6 years ago
Created attachment 599478 [details] [diff] [review]
add Vector::sizeOf{In,Ex}cludingThis

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.
Attachment #599478 - Flags: review?(luke)
(Assignee)

Comment 1

6 years ago
Created attachment 599479 [details] [diff] [review]
add js/runtime/gc-marker

Pretty simple.  Bill, does the MarkStack ever shrink?  If not, it's the kind of thing that hurts us w.r.t. bug 668809.
Attachment #599479 - Flags: review?(wmccloskey)

Updated

6 years ago
Attachment #599478 - Flags: review?(luke) → review+
(Assignee)

Comment 2

6 years ago
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.
Attachment #599479 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 4

6 years ago
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'"
(Assignee)

Updated

6 years ago
Depends on: 728990
(Assignee)

Comment 6

6 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Depends on: 733374
(Assignee)

Comment 8

6 years ago
A tiny follow-up to fix a runtime warning:

https://hg.mozilla.org/integration/mozilla-inbound/rev/a0f77fee1568
https://hg.mozilla.org/mozilla-central/rev/a0f77fee1568
You need to log in before you can comment on or make changes to this bug.