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)
Core
JavaScript: GC
Tracking
()
RESOLVED
FIXED
mozilla43
People
(Reporter: terrence, Assigned: terrence)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
4.49 KB,
patch
|
jonco
:
review+
|
Details | Diff | Splinter Review |
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 1•9 years ago
|
||
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
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in
before you can comment on or make changes to this bug.
Description
•