tsgo crashes with OOM on Windows when turbo typecheck runs in parallel on heavily loaded machines

Description

tsgo (@typescript/native-preview) crashes with fatal error: out of memory when bun turbo typecheck runs 30 packages in parallel on Windows. The root cause is Windows commit limit exhaustion: the Go runtime allocates committed memory proportional to the number of parallel processes, and when the system commit limit (RAM + pagefile) is nearly exhausted by other processes, the parallel startup spike exceeds the remaining commit budget.

This only affects machines that are heavily loaded. On systems with plenty of free commit memory, unlimited parallelism works fine.

Root cause analysis:

The Go runtime GC grows the heap based on GOGC (default: 100, meaning heap doubles before GC triggers). Per the Go GC guide (https://tip.golang.org/doc/gc-guide), each Go process reserves ~700 MB of virtual address space on 64-bit, but this is not committed. The actual committed memory (private bytes) per tsgo process peaks at ~84 MB during startup (measured), then settles to ~19 MB steady-state working set.

tsgo --checkers (default: CPU count) further multiplies memory per process — microsoft/typescript-go#4201: "More threads does mean more memory consumption" and "each checker re-instantiates the shared library surface."

When turbo runs 30 tsgo processes in parallel with no concurrency limit, the combined startup spike (30 × ~84 MB = ~2.5 GB committed) can exceed the available commit budget.

Measured data (Windows 11, 16 GB RAM, 16 GB pagefile, 32 GB total commit, system at ~94% commit):

t=0s: 18 tsgo processes, 180 MB private,  468 MB free commit
t=2s: 20 tsgo processes, 561 MB private,   64 MB free commit  → STACK OVERFLOW (errno=1455)
t=4s: 19 tsgo processes, 747 MB private,   24 MB free commit  → crash
t=6s: tsgo exited,                        1871 MB free commit  → recovered

Per-process peak (top 5, during startup spike):

PID    WorkingSet  PrivateMem
52992  56.8 MB     64.3 MB
44236  51.3 MB     57.0 MB
60108  40.8 MB     47.0 MB
49660  35.7 MB     40.9 MB
34344  35.8 MB     40.5 MB

After reboot (6.7 GB free commit): bun turbo typecheck with no limit succeeds — 8/30 tasks pass, no OOM. The 22 failures are genuine TS errors (e.g. Cannot find module 'bun:test'), not memory crashes.

With only 215 MB free commit (heavy system load), even --concurrency=2 crashes.

Proposed fix:

A dynamic concurrency limit script (script/typecheck.ts) that calculates safe parallelism at runtime:

concurrency = max(1, min(cpuCount, floor(freeCommitMB / 100)))

Where:

• cpuCount — upper bound (no point running more processes than CPUs; avoids context-switching overhead when memory is plentiful)
• freeCommitMB — available commit memory, measured via OS APIs (os.freemem() as proxy on Windows, or WMI Win32_OperatingSystem.FreeVirtualMemory)
• 100 MB — conservative per-process startup spike estimate, derived from:
  • Measured peak private memory per tsgo process: ~84 MB
  • Go GC guide: GOGC default = 100 → heap doubles before GC; base live heap ~40 MB × 2 = ~80 MB
  • Rounded up to 100 MB for safety margin

This replaces bun turbo typecheck in the typecheck script in package.json:

"typecheck": "bun run script/typecheck.ts"

This only matters on heavily loaded machines. On systems with ample free commit (e.g. >2 GB), the formula yields min(cpuCount, floor(freeCommitMB/100)) which typically equals cpuCount — no change in behavior. The limit only kicks in when memory is scarce.

Related upstream issues:

• golang/go#75407 (closed, "not planned") — Go runtime errno=1455 on Windows
• golang/go#75417 (open) — umbrella issue for Windows paging file exhaustion
• microsoft/typescript-go#4201 — tsgo peak RSS scales with --checkers
• microsoft/typescript-go#1622 — tsgo --build uses extreme amounts of memory; --singleThreaded and --maxConcurrentProjects as mitigations

Plugins

N/A (development tooling issue)

OpenCode version

dev branch (commit 228e909)

Steps to reproduce

1. On Windows 11 with heavy memory usage (e.g. 6+ opencode instances, Outlook, Edge — system at ~94% commit, <500 MB free)
2. Run bun turbo typecheck from repo root
3. tsgo processes crash with fatal error: out of memory / errno=1455 / STATUS_STACK_BUFFER_OVERRUN
4. All 30 typecheck tasks fail (0 successful)

Verification:

• After reboot (6.7 GB free): bun turbo typecheck succeeds (no OOM), only genuine TS errors remain
• With --concurrency=4 and >400 MB free: no OOM crashes
• With 215 MB free: even --concurrency=2 crashes

Screenshot and/or share link

N/A

Operating System

Windows 11 (16 GB RAM, 16 GB pagefile, 32 GB total commit limit, 8 CPUs)

Terminal

Windows Terminal / PowerShell 7