Closed Bug 1192304 Opened 9 years ago Closed 9 years ago

Common up the checks we do in abortGC and collect

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox42 --- affected
firefox43 --- fixed

People

(Reporter: terrence, Assigned: terrence)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

At the start of every collection event, we check that the runtime is in a valid place for any sort of GC event to have occurred. These checks appear to have diverged between abortGC and collect. I also split off the is-gc-allowed check because somehow the TraceLogger event was getting fired before we'd finished these checks: probably doesn't matter because we're unlikely to run with both trace logging and deterministic mode, but still worth fixing.
Attachment #8645025 - Flags: review?(jcoppeard)
Comment on attachment 8645025 [details] [diff] [review]
1_split_out_per_gc_event_logic-v0.diff

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

::: js/src/gc/GCRuntime.h
@@ +897,5 @@
> +    void resetIncrementalGC(const char* reason);
> +
> +    // Assert if the system state is such that we should never
> +    // receive a request to do GC work.
> +    void sanityCheckGCEventRequest();

I can't help thinking there's a better name for this... checkCanCallAPI() maybe?
Attachment #8645025 - Flags: review?(jcoppeard) → review+
https://hg.mozilla.org/mozilla-central/rev/9c9f970f1fff
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.