Closed
Bug 857345
Opened 12 years ago
Closed 12 years ago
Don't UnmarkGray on nursery allocated things
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla23
People
(Reporter: terrence, Assigned: terrence)
References
Details
Attachments
(1 file)
3.38 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
They don't have mark bits and, indeed, cannot be gray: we do a minor collection at the start of each GC slice, so the gray marker should never be able to observe a gc thing in the nursery. The only tricky thing here is ensuring that we don't regress performance.
Talos run at:
https://tbpl.mozilla.org/?tree=Try&rev=d0192b42ccd3
Attachment #732572 -
Flags: review?(wmccloskey)
The Talos run was done without JSGC_GENERATIONAL set, so it wasn't really testing anything. Can you run it again without the ifdefs?
Assignee | ||
Comment 2•12 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #1)
> The Talos run was done without JSGC_GENERATIONAL set, so it wasn't really
> testing anything. Can you run it again without the ifdefs?
Right, I thought we wanted to ensure that flipping the order of the other tests doesn't regress, since switching on GGC is going to have so many other effects. It certainly won't hurt to re-test with the #ifdefs commented out, however: https://tbpl.mozilla.org/?tree=Try&rev=68864c0d9a36
Assignee | ||
Comment 3•12 years ago
|
||
No regression that I can see, even on my nemesis platform, WinXP.
Comment on attachment 732572 [details] [diff] [review]
v0
Review of attachment 732572 [details] [diff] [review]:
-----------------------------------------------------------------
::: js/public/GCAPI.h
@@ +245,5 @@
> + * each GC slice, so the gray marker never sees nursery things.
> + *
> + * This test is incorrect when running the post-barrier verifier, as it does
> + * not check the verifier nursery. This is safe, however, since the verifier
> + * uses only the tenured heap.
This second paragraph is confusing and doesn't really add anything IMO. Please remove it.
Attachment #732572 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 5•12 years ago
|
||
Comment 6•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Comment 7•12 years ago
|
||
Is JSGC_GENERATIONAL defined correctly outside jseng?
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to :Ms2ger from comment #7)
> Is JSGC_GENERATIONAL defined correctly outside jseng?
Not yet (at least to the best of my knowledge). However, these are also used inside spidermonkey, so they did receive testing. Adding --enable-gcgenerational to the top-level configure will be one of the first things I need to do once I start serious work on the browser.
You need to log in
before you can comment on or make changes to this bug.
Description
•