Closed Bug 1337450 Opened 8 years ago Closed 8 years ago

Simplify the implementation of GC resets

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: jonco, Assigned: jonco)

References

Details

Attachments

(1 file)

Attached patch simplify-abort-incremental (deleted) — Splinter Review
At the moment we call GCRuntime::resetIncrementalGC from several places. This patch changes things so that this always happens from budgetIncrementalGC. The implementation of abortGC now just starts a collection with the ABORT_GC reason which that method checks for. This is needed for running the GC from its own thread because it means that resets now always happen on the GC thread.
Attachment #8834504 - Flags: review?(sphink)
Comment on attachment 8834504 [details] [diff] [review] simplify-abort-incremental Review of attachment 8834504 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jsgc.cpp @@ +6224,1 @@ > if (prevState != State::NotActive && !isIncrementalGCInProgress()) Would it be possible to eliminate this test? It feels like it's inferring what budgetIncrementalGC did, instead of having it just tell it directly. Maybe: budgetIncrementalGC(nonincrementalByAPI, reason, budget, &resetGC, session.lock); if (resetGC) return true; Unless there's some nuance I'm missing. Or, given that we're already using a boolean return from gcCycle to mean wasReset, I suppose we could do the same here. Or better, change both of them to an enum { GCWasReset, GCWasNotReset }. Ugh, those names are pretty bad. enum class GCResult { Ok, Reset }? @@ -6471,5 @@ > checkCanCallAPI(); > MOZ_ASSERT(!TlsContext.get()->suppressGC); > > - AutoStopVerifyingBarriers av(rt, false); > - AutoEnqueuePendingParseTasksAfterGC aept(*this); Heh, seems we had another batch of these nested inside collect(). Yay for getting rid of lots of redundant goop here.
Attachment #8834504 - Flags: review?(sphink) → review+
(In reply to Steve Fink [:sfink] [:s:] from comment #1) > Or, given that we're already using a boolean return from gcCycle to mean > wasReset, I suppose we could do the same here. Or better, change both of > them to an enum { GCWasReset, GCWasNotReset }. Ugh, those names are pretty > bad. enum class GCResult { Ok, Reset }? That is a great idea, I'll do that.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: