The default bug view has changed. See this FAQ.

GC: Eliminate per-compartment barrier marker

RESOLVED FIXED in mozilla13

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: billm, Assigned: billm)

Tracking

unspecified
mozilla13
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Created attachment 601754 [details] [diff] [review]
patch

We don't need this anymore since the runtime is now single-threaded.

I also fixed GCMarker::stop so that it releases memory that was allocated during the collection.
Attachment #601754 - Flags: review?(igor)
Whiteboard: [MemShrink]

Comment 1

5 years ago
Comment on attachment 601754 [details] [diff] [review]
patch

Review of attachment 601754 [details] [diff] [review]:
-----------------------------------------------------------------

Nice!
Attachment #601754 - Flags: review?(igor) → review+
(Assignee)

Comment 2

5 years ago
Just so it's clear, this won't decrease memory usage by much at all. The stuff that we were pushing onto the per-compartment mark stack will now be pushed onto the per-runtime mark stack. But I guess that's a little better from a memshrink perspective because we have a memory reporter for the latter and not for the former.
> Just so it's clear, this won't decrease memory usage by much at all.

I clarified this with billm on IRC.  With heavy usage the MarkStack can grow a lot.  E.g. with MemBench it gets up to 2.8MB.  Prior to this patch, once grown it would never shrink again, but with this patch it will shrink back to 256KB.
(Assignee)

Comment 4

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/fbdaf507dcb5
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/fbdaf507dcb5
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.