Runtime GC Pause Bursts and Dispatch-Phase Slippage (Practical Playbook)

Date: 2026-03-16
Category: research
Audience: small quant teams running low-latency execution stacks (JVM/Go/Node/Python)

Why this matters

Most slippage stacks model market microstructure well but treat application runtime as "outside noise."
In live execution, that assumption fails when garbage collection (GC) pauses and allocator pressure create dispatch bunching:

• scheduler misses child-order slots,
• then emits catch-up bursts,
• queue priority degrades,
• late urgency increases taker usage,
• tail implementation shortfall widens.

This is not a rare infra curiosity. It is a repeatable control-loop distortion between strategy intent and wire-time execution.

1) Failure mechanism (from heap pressure to bps leak)

A practical causal chain:

1. Allocation spikes (market-data bursts, short-lived object churn)
2. Runtime pauses or mutator throttling (STW or effective pause)
3. Event-loop / scheduler lag grows
4. Child-order cadence drifts from planned schedule
5. Post-pause catch-up sends clustered child slices
6. Queue-entry timing worsens, adverse selection rises
7. Router switches to aggressive fallback near deadline
8. Realized IS tail (q95+) degrades

Treat this as a pipeline incident class, not a one-off anomaly.

2) Metrics that expose GC-driven slippage

Core telemetry

• gc_pause_ms_p95/p99 by process and minute
• event_loop_lag_ms_p95 (or scheduler lag)
• dispatch_interval_error_ms = |actual_child_gap - target_gap|
• pending_child_backlog (unsent intent queue)
• catchup_burst_size (children sent within short burst window)

Execution-coupled metrics

1. Dispatch Drift Ratio (DDR)

[ DDR = \frac{\text{median}(|\Delta t_{actual}-\Delta t_{target}|)}{\Delta t_{target}} ]

2. Burst Compression Index (BCI)

[ BCI = \frac{#\text{children in }[0,\tau]\text{ post-pause}}{#\text{children expected in }[0,\tau]} ]

3. Queue Age Loss (QAL)

Approximate expected queue-age erosion from bursty re-entry vs planned cadence.

4. GC-linked Slippage Uplift (GSLU)

[ GSLU = IS_{bps}^{pause_windows} - IS_{bps}^{matched_nonpause_windows} ]

If DDR/BCI rise while GSLU widens, runtime is now a first-class slippage driver.

3) Modeling branch cost (pause-aware expected cost)

Use a simple branch model for each decision interval:

[ E[\Delta IS] = p_{on_time}C_{on_time}+p_{delayed}C_{delayed}+p_{burst}C_{burst}+p_{deadline_cross}C_{deadline_cross} ]

Where branch probabilities are conditioned on:

• runtime state (gc_pause_p99, heap headroom, alloc rate)
• scheduler state (event-loop lag, backlog)
• market state (spread, depth resiliency, toxicity proxies)

Operationally, C_burst and C_deadline_cross are often underestimated in mean-only models. Fit q90/q95 explicitly.

4) Control policy (runtime-aware execution states)

GREEN (stable runtime)

• Normal cadence
• Standard participation cap
• Regular venue ranking

AMBER (pause risk rising)

• Trigger: gc/event-loop lag threshold breach for N windows
• Action: reduce child size variance, widen cadence buffers, limit optional retries

RED (active pause or burst recovery)

• Trigger: pause active or DDR/BCI hard breach
• Action: disable catch-up burst behavior, switch to paced recovery ladder, temporarily reduce venue churn

SAFE (tail protection)

• Trigger: repeated GSLU breach or deadline risk spike
• Action: conservative completion path with bounded aggression and hard max participation

Key rule: never let the scheduler "repay missed slices" in one burst without guardrails.

5) Engineering mitigations by layer

Runtime layer

• Keep heap headroom above stress percentile (avoid cliff near max heap)
• Prefer low-pause collectors where suitable (e.g., tuned G1/ZGC/Shenandoah; Go GC tuning)
• Reduce allocation churn on hot paths (object reuse, buffer pools, preallocation)
• Pin critical execution loops away from noisy allocation-heavy services when possible

Process architecture

• Isolate market-data parsing and execution dispatch into separate processes/threads
• Use bounded queues between components; surface backlog as an SLO
• Add deterministic pacing component independent of GC-heavy code paths

Policy layer

• Replace naive catch-up with bounded repayment (max extra slices per interval)
• Add cooldown after pauses before resuming normal aggressiveness
• Tie fallback aggression to tail budget, not just elapsed schedule deficit

6) Validation plan (7-day practical rollout)

Day 1-2
Instrument gc/event-loop/dispatch metrics and tag execution windows.

Day 3-4
Build matched-window attribution (pause vs non-pause) and estimate GSLU.

Day 5
Enable AMBER/RED policy in shadow mode (no live action, decision logging only).

Day 6
Canary live on small symbol bucket with hard rollback gates.

Day 7
Review q95 IS, completion rate, and burst incidence; expand only if all gates pass.

Rollback trigger example:

• q95 IS worsens > 8 bps vs control for 2 consecutive sessions, or
• completion reliability drops below pre-defined floor.

7) Common anti-patterns

1. "Infra issue, not trading issue" mindset
   Runtime incidents still hit execution PnL; model them.

2. Mean-only monitoring
   Pause damage is tail-heavy; q95/q99 is the main signal.

3. Aggressive catch-up logic
   Repaying schedule debt instantly is usually queue-priority suicide.

4. No co-analysis with market state
   Same pause length has different cost in calm vs fragile books.

Bottom line

GC pause behavior is not merely a systems-health metric. In automated execution, it is a microstructure timing variable.
If runtime observability is disconnected from slippage attribution, teams will keep misdiagnosing tail losses as "random market noise."

Treat pause risk as a modeled branch in the execution controller, and most of the avoidable runtime-induced bps leakage becomes governable.

References

• Oracle, Garbage First Garbage Collector Tuning
  https://docs.oracle.com/en/java/javase/21/gctuning/garbage-first-garbage-collector-tuning.html

• OpenJDK JEP 333, ZGC: A Scalable Low-Latency Garbage Collector
  https://openjdk.org/jeps/333

• OpenJDK JEP 189, Shenandoah: A Low-Pause-Time Garbage Collector
  https://openjdk.org/jeps/189

• Go Team, A Guide to the Go Garbage Collector
  https://go.dev/doc/gc-guide

• Node.js Docs, perf_hooks (event loop delay monitoring)
  https://nodejs.org/api/perf_hooks.html