Problem
The opt-in no-GIL mid-script parallel collector can consume the only checkpoint after a JavaScript gc() request with the retry cooldown installed by #907.
A full threadfuzz midgc sweep failed the Thread.restrict lifecycle witness at seed 146 with:
attempts = 1
collections = 0
aborts = 1
round_limit_aborts = 1
generations = 64
born_growth_rounds = 57
finish_retries = 7
backoff_skips = 1
topology_retry_bypasses = 0
backoff_limit_bypasses = 0All running peers published every generation. The first attempt safely aborted after continuous allocation. The workload then called the shell gc() helper, which set gc_requested, but serviceParallelGc checked the retry cooldown and ordinary heap threshold before treating that explicit request as due. The single remaining eligible checkpoint was skipped, so no finishing sweep occurred.
The failure is scheduling-sensitive: eight isolated repetitions of the exact seed passed. This is the same low-frequency shape discussed in #907, whose one-safepoint cooldown bound still permits the first skipped checkpoint to be the final checkpoint.
Definition of done
- A pending explicit
gc()/host collection request bypasses the opportunistic retry cooldown and heap-pressure threshold in the parallel mid-script collector. - A successful parallel sweep clears the explicit request; abort-safe failures leave it pending.
- A focused
Thread.restrictmid-GC runner can repeat the exact witness without paying for all 45 mid-GC cases per seed. - Focused normal and unsuppressed TSan repetitions pass, along with the full mid-GC gate and relevant unit coverage.
- Preserve the existing publication/round budgets and ordinary opportunistic cooldown behavior.