Last Comment Bug 744489 - Fix incremental GC assertion in ValidateIncrementalMarking
: Fix incremental GC assertion in ValidateIncrementalMarking
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
-- normal (vote)
: mozilla14
Assigned To: Bill McCloskey (:billm)
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2012-04-11 11:07 PDT by Bill McCloskey (:billm)
Modified: 2012-04-13 04:25 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (2.75 KB, patch)
2012-04-11 11:07 PDT, Bill McCloskey (:billm)
igor: review+
Details | Diff | Splinter Review

Description User image Bill McCloskey (:billm) 2012-04-11 11:07:59 PDT
Created attachment 614066 [details] [diff] [review]

I was a little overzealous in bug 739899 when I tried to remove all full GC flags. As a consequence, the following can now happen:

1. Start an incremental GC with all compartments being collected. Therefore, the atoms compartment can be collected.
2. A new compartment is created
3. When the GC is finished, call ValidateIncrementalMarking.
4. It calls MarkRuntime again. This time, since the new compartment is not being collected, we mark all atoms.
5. ValidateIncrementalMarking asserts because the incremental GC didn't mark all the atoms, while the non-incremental one did.

This is a bogus assertion. We're not required to mark all atoms in this situation. Any atoms pointed to by the new compartment either existed before or else they were new, and we'll mark them either way.

The patch just adds a "full GC" flag that is set at the beginning of the incremental GC and used by both calls to MarkRuntime.
Comment 2 User image Marco Bonardo [::mak] 2012-04-13 04:25:57 PDT

Note You need to log in before you can comment on or make changes to this bug.