Racket Thread Scheduler and Garbage Collector Interaction Under Concurrent Requests

Direct answer

There is no fixed allocation rate or heap size that triggers a stop‑the‑world GC while the scheduler lock is held. Racket triggers a collection at an allocation point when the bytes allocated since the last GC exceed a fraction of the current heap size; that fraction is governed by the gc-threshold parameter. The commonly cited default is roughly 0.5, but the exact value is not part of the public API and can differ between releases. The latency spike you observe is therefore a probabilistic overlap, not a deterministic threshold.

Confirmed behavior vs. likely explanation

Confirmed: Racket protects its run queue with a single scheduler mutex that is acquired on context switches and scheduler‑state access. The garbage collector is stop‑the‑world and runs at allocation points. gc-threshold controls how much allocation is tolerated before the next collection.

Likely explanation: when a thread allocates enough to cross the GC threshold while it already holds the scheduler lock, the collector must wait for the lock to be released before it can pause all threads. That adds the lock‑hold time to the pause. Under heavy concurrency the chance of this overlap rises with both the number of threads and the per‑thread allocation rate.

Thresholds, heuristics, and GC concurrency

• Documented threshold or heuristic: none is published. The only tunable is gc-threshold; there is no formula that maps a specific allocation rate to a guaranteed pause.
• Configurable GC concurrency or lock decoupling: current stable Racket does not expose a concurrent or incremental GC mode, nor a way to decouple scheduler pauses from GC pauses. No public policy or roadmap for such a feature appears in the documented interfaces.

Practical verification

Isolate the effect by removing other pause sources and comparing allocation‑heavy vs. allocation‑light workloads. A safe, scoped benchmark looks like this:

(require racket/gc)

(parameterize ([gc-threshold 0.5])
  (gc-stats #t)
  (define N 50)
  (define threads
    (for/list ([i (in-range N)])
      (thread
       (lambda ()
         (let loop ()
           (define t0 (current-inexact-milliseconds))
           (make-bytes 100000)   ; allocation-heavy work
           (yield)
           (define t1 (current-inexact-milliseconds))
           (when (> (- t1 t0) 5.0)
             (printf "thread ~a pause ~a ms\n" i (- t1 t0)))
           (loop))))))
  (for ([t (in-list threads)]) (thread-wait t)))

Repeat with (parameterize ([gc-threshold 0.8]) …) and verify that pause frequency drops. If pauses shrink only in the allocation‑heavy case, the scheduler‑lock/GC interaction is the likely source.

Mitigation options

1. Raise gc-threshold to reduce GC frequency at the cost of higher memory use.
2. Reduce per‑request allocation by reusing buffers or avoiding intermediate data structures.
3. Limit thread count to roughly the number of available cores if the workload is allocation‑bound.

One diagnostic detail needed

Please confirm the exact Racket version you are running. Because the default gc-threshold and internal GC heuristics can vary by release, the version determines whether the approximate 0.5 factor applies and whether tuning gc-threshold is the right first step.