Remove off-main-thread GC trigger checks

RESOLVED INVALID

Status

()

RESOLVED INVALID
4 years ago
2 years ago

People

(Reporter: terrence, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
The ExclusiveContext has full access to the Zone, so I think the only thing blocking this is concurrent access to rt->gc.incrementalGCState.
(Reporter)

Comment 1

4 years ago
Actually, I don't think it makes sense to trigger any GCs from off-main-thread. I was under the impression that if we OOM'd we'd retry the parse on the main thread, so triggering a GC would streamline the next on-thread alloc. This is not the case, instead we just report the OOM. Moreover, the one trigger that is safely checked off-thread -- maybeTriggerZoneGC -- is not actually effectual when run off-thread because triggerZoneGC explicitly bails if we try. Further, we can't even pause the off-thread for the main thread to do a GC here since we'd certainly deadlock.

Given that we're fine with the current situation and there's nothing we can do anyway, I think the right answer is to just simplify all of this code and only bother checking for GC on the main thread.
Summary: Allow IGC_TOO_SLOW GC to be triggered by off-thread allocation → Remove off-main-thread GC trigger checks
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1131204
(Reporter)

Comment 3

2 years ago
And we really don't do this. Hopefully, it's even clear in the new allocator that this is the case.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.