The ExclusiveContext has full access to the Zone, so I think the only thing blocking this is concurrent access to rt->gc.incrementalGCState.
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
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.