Closed
Bug 906091
Opened 12 years ago
Closed 12 years ago
GC: MarkGlobalForMinorGC() slows down root marking for minor GC
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla27
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(3 files, 2 obsolete files)
In a browser build, by far the greatest contribution to the runtime of MarkRuntime() in a minor GC is calling MarkGlobalForMinorGC(). This marks all the non-reserved slots of the global for every compartment in the system.
Assignee | ||
Comment 1•12 years ago
|
||
This breakdown shows times in microseconds for the various parts of MarkRuntime(). The first column "Minor" is the total, and "GlobMin" is the result of calling MarkGlobalForMinorGC().
Assignee | ||
Updated•12 years ago
|
Attachment #791337 -
Attachment mime type: text/x-log → text/plain
Assignee | ||
Comment 2•12 years ago
|
||
The comments in MarkGlobalForMinorGC() indicate that this is done to avoid barriers on writes to the global's slots. Would it be possible to add these barriers, or would that have its own performance penalty?
Flags: needinfo?(bhackett1024)
Comment 3•12 years ago
|
||
I avoided the barriers on global object slots because one of the octane benchmarks (earley boyer) I think was just adding a ton of entries for global writes and exhausting the store buffer very quickly. I thought in the browser context this was just done for compartments with Ion code, but maybe that's changed. In any case there are other options for dealing with this --- try to avoid adding store buffer entries for globals when they are already known to be in the store buffer, or keep more precise track of the globals or even {global,slot} tuples which Ion writes to without post barriers.
Flags: needinfo?(bhackett1024)
Assignee | ||
Comment 4•12 years ago
|
||
Patch to add globals to the storebuffer on the first write only.
I can tidy this up and un-duplicate the LIR/MIR nodes by setting a flag if the object is a global.
I saw some crashes with this in the browser, but I haven't worked out whether they are existing issues.
Assignee: general → jcoppeard
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•12 years ago
|
||
qref'd patch this time
Assignee | ||
Updated•12 years ago
|
Attachment #799626 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Blocks: GenerationalGC
Assignee | ||
Comment 6•12 years ago
|
||
Post barrier writes to globals, but add a flag in JSCompartment to only put cell in the store buffer once.
MarkRuntime times are much reduced and v8 benchmarks are unaffected.
Attachment #799640 -
Attachment is obsolete: true
Attachment #808649 -
Flags: review?(terrence)
Assignee | ||
Comment 7•12 years ago
|
||
Some MarkRuntime timings with patch applied.
Assignee | ||
Updated•12 years ago
|
Attachment #808650 -
Attachment mime type: text/x-log → text/plain
Comment 8•12 years ago
|
||
Comment on attachment 808649 [details] [diff] [review]
post-barrier-global
Review of attachment 808649 [details] [diff] [review]:
-----------------------------------------------------------------
Very nice! r=me
::: js/src/jscompartment.h
@@ +205,5 @@
>
> /* Set of all currently living type representations. */
> js::TypeRepresentationHash typeReprs;
>
> + bool globalWriteBarriered;
This could use a fairly detailed comment explaining what state it is tracking and why.
Attachment #808649 -
Flags: review?(terrence) → review+
Assignee | ||
Comment 9•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in
before you can comment on or make changes to this bug.
Description
•