Collect transient native-emitter garbage on heap growth

[oxura]

Fixes the default-GC emission pressure reported in #1262. This addresses suggestion 1 (collect transient emission garbage), not the independent incremental-emission design in open #1386. I rechecked open PRs referencing #1262 before submitting; #1386 is the only existing one.

Change

Sample Bun heap use every 64 emitted definitions. Once it exceeds 2 GiB, collect; set the next checkpoint to the post-collection live heap plus 2 GiB. This avoids using physical host RAM as the transient-garbage budget and avoids repeatedly collecting large live books that cannot be reclaimed. No re-exec, global JSC environment override, scheduling rewrite, or per-definition full GC.

The guarded checkpoint leaves non-Bun compilation unchanged. README states the resource policy and explicitly says live state is not capped. No GUIDE or CHANGELOG edit; no protected checker/kernel/gate/allow-list/cap changes.

Actual before/after

Same public Chromi Eco entry, same dependency revisions and Linux x64 host (31 GiB RAM), same Bun executable. BUN_JSC_forceRAMSize was unset. The unchanged source compiler is main 2343aec; the treatment differs only by this checkpoint and its documentation.

Executed compiler	Peak RSS (KiB)	Wall time (s)	Status
Source, before	4483420	27.35	0
Source, after	3026800	26.58	0
Genuine installed-layout compiled CLI, after	3059936	26.60	0

All three generated C files are byte-identical, checked with cmp; SHA-256: 1170f0ac04a8116080efadd8394bc896eaf5cc05a6f373ad2bbbaa2be4ba0f34.

Repository shape/cap gate: 54/54. No nondeterministic memory assertion added to the permanent test suite.

Limits: the issue's private 27k-line Darwin application was unavailable; this is a real public large application, not a reproduction claim for that exact input. No Darwin/GPU run. This is a heap-growth collection policy, not a hard RSS limit and not a solution to intrinsically oversized live compiler state.

[nicolas-abril]

Unsupervised AI review (Claude, run by @nicolas-abril). Nobody has read this by hand yet, so please double-check it.

I pushed a commit on top of this PR with the same policy in fewer tokens:

• I dropped the emitted & 63 counter, so the heap is now sampled at every def. In Bun, process.memoryUsage() takes about 0.6 µs, so even 1,800 defs over a few passes cost only a few milliseconds.
• typeof Bun !== "undefined" && … Bun.gc(true) became globalThis.Bun?.gc(true).
• This saves 20 tokens. Merged onto current main (d71f42e), comp.ts goes from 64,014 (14 over the cap) to 63,994 (under it).

Checks on macOS: gates/repo.ts 54/54 and gates/test.ts 1600/1600. The C emitted for all 17 runtime benches is byte-identical to this PR's head. Compiling raytrace takes 105.7 ± 2.5 ms (PR) vs 105.3 ± 2.8 ms (this commit). I couldn't rerun the Chromi Eco measurement because I don't have it set up here. The collection policy itself didn't change.

I also didn't look further into what makes the emitter produce so much garbage. That would be the fix at the root.

[oxura]

Thanks; I checked the current 5342ce14 head on Linux and kept your simplification unchanged.

The actual public Chromi Eco workload (Chromi 70555a40, with the dependency revisions recorded in the original qualification) still compiles successfully. The emitted C is 13,320,678 bytes and byte-identical to the prior PR-head artifact:

sha256 1170f0ac04a8116080efadd8394bc896eaf5cc05a6f373ad2bbbaa2be4ba0f34

The observed peak RSS was 3,683,340 KiB and elapsed time 32.27 s. Those are standalone observations, not a claimed timing/memory improvement: there is no fresh controlled timing baseline, and the original private Darwin input is still unavailable. gates/repo.ts passes 54/54 on this head.

I did not investigate a broader emitter-allocation redesign, launch the graphical Eco application, or claim the private macOS memory report fixed.

[nicolas-abril]

AI-written review (Claude, for @nicolas-abril).

Pushed 10444e7 on top of 5342ce1. It drops the README note, which still said "every 64 definitions" and was wrong after 5342ce1. It also drops the code comment and calls Bun.gc(true) directly: the compiler only runs under Bun, and main.ts already calls Bun.gc(true) with no guard. The PR now adds 5 lines to comp.ts.

Measured on a 16 GB M-series Mac. This is the machine class from #1262. I used the Chromi Eco example with the sibling repos at their Oct 10 commits. Every run gave byte-identical C, with sha256 1170f0ac04a8….

Compiler	Peak RSS
base 2343aec	4.08 GB, 5.31 GB (two runs)
5342ce1	3.61 GB, 3.37 GB
10444e7	3.70 GB
base + BUN_JSC_forceRAMSize=2GiB	2.35 GB

The machine was loaded (load average ~22), so wall times aren't meaningful.

Gates on 10444e7 (macOS): repo 54/54, ping 47/47, test 1600/1600, perf 124/124. Not run: Linux, CUDA.

Before merge: merged onto current main, comp.ts is 64,138 ttok against the 64,000 cap. Main alone is already 64,092 since #1588, so this needs main back under the cap first, or a rebase that pays for the 46 tokens.

Scope: this mitigates #1262 but doesn't fix its root cause. It works around Bun sizing its heap from physical RAM. It does nothing about how much short-lived garbage emission makes, or about compile_book re-emitting every def on each fixed-point pass (#1386).