Racket Thread Scheduler and Garbage Collector Interaction Under Concurrent Requests

Goal: isolate the latency that appears only when many Racket threads handle requests simultaneously, focusing on how the global thread‑scheduler lock and the stop‑the‑world garbage collector interact.

Constraints: the current runtime uses a single scheduler lock that serializes context switches, and the GC pauses all threads; the exact conditions that trigger a GC pause while the lock is held are not specified, and there is no published policy for when Racket might adopt a concurrent or incremental collector.

Uncertainty: without this information it is hard to predict latency spikes or to tune thread‑pool sizes for workloads that allocate heavily during peak concurrency.

Questions: What allocation rate or heap size triggers a stop‑the‑world GC while the scheduler lock is held? Is there a documented threshold or heuristic that predicts the latency spike? Are there plans to expose a configurable GC concurrency mode or to decouple the scheduler lock from GC pauses?