gc: block-persistence conservatism inflates peak RSS on tight allocation loops

[proggeramlug]

Summary

Perry's GC includes a "block-persistence" pass at crates/perry-runtime/src/gc.rs:1090 that marks ALL objects in an 8 MB arena block live whenever any single object in the block is root-reachable. This was added to protect against untracked arena refs sitting in caller-saved registers that the conservative stack scan can't capture (issues #43 / #44 pattern — dangling-pointer crashes when GC freed still-reachable arena objects).

The conservatism is catastrophic for tight allocation loops that co-locate fresh per-iteration data with pre-existing long-lived state. The JSON.parse case was traced in detail in #149; summary of the mechanism:

1. Block 0 (and sometimes block 1) contains long-lived data: interned string keys, shape-cache keys_arrays, the blob being parsed, any caller-level root arrays.
2. The same block also contains early-iteration allocations (the first new Foo() in the loop always lands adjacent to the setup data).
3. Every subsequent iteration's allocations go into new blocks.
4. GC marks block 0 live (because of the long-lived data). Block-persist marks EVERY object in block 0 live — including the dead early-iteration objects.
5. Those dead objects have field values pointing into later blocks (fresh name strings, tag arrays, nested objects).
6. The persist pass iterates to fixed point, following pointers across blocks — at iter 49 of bench_json_roundtrip, 2 live blocks / 37 truly-reachable objects cascaded to 30 live blocks / 3 M "live" objects over 11 rounds.
7. gc() becomes a no-op. RSS grows linearly with iteration count.

Measured impact (bench_json_roundtrip at v0.5.190)

	Perry	Bun	ratio
Speed	315 ms	248 ms	1.27×
Peak RSS	318 MB	83 MB	3.83×

The speed gap is tolerable (recently closed from 2.4× to 1.27×, see #149 closeout). The RSS gap is the architectural cost of block-persist + bump-arena vs. Bun's per-object GC.

Not just JSON

Any tight new ClassName() / new Array() / tight parser loop that runs after meaningful setup hits the same pattern. The setup's long-lived roots anchor block 0 live; the first loop iteration allocates adjacent to them; block-persist pulls in the dead iter-0 objects on every GC and cascades from there.

We've seen the contours of this before:

• items.push({...}) builds that produce megabytes of structure but only length is read later
• Repeated Buffer.alloc with const buf = Buffer.alloc(1024) in a loop (before the perf(runtime): fast-path small Buffer.alloc via per-thread bump slab #173 slab fast-path)
• new Map() build loops
• (probably) any perry/thread workload that cycles large intermediate state

Fix directions

Ranked by scope.

A. Segregated long-lived arena region (medium)

Allocate intrinsically long-lived data — PARSE_KEY_CACHE strings, shape-cache keys_arrays, transition-cache arrays, the string intern table, stringify scratch — into a DEDICATED arena block (or a small fixed-size region) that block-persist can conservatively retain. Everything else goes into the general arena where per-iter blocks genuinely go dead together.

Small scope (no correctness tradeoff with #43 / #44), but needs careful routing: every long-lived allocation path has to opt in.

B. Weaken block-persist with a stricter pre-condition (high)

Block-persist exists because the conservative stack scan can miss handles in caller-saved registers during mid-parse GC triggers. If we can guarantee (by convention + scaffolding in js_json_parse, js_buffer_alloc, etc.) that all intermediate arena refs from a given path are tracked in an explicit root set (like PARSE_ROOTS) before any internal allocation, we can skip block-persist for those paths.

Would need a comprehensive audit of allocation call sites. Higher risk — re-opens the failure mode #43 / #44 closed.

C. Generational GC (largest)

Young generation = throwaway per-GC-cycle region; old generation = current arena model. Most parse output is trivially young-generation (dies before first GC). Matches what Bun/V8 do.

Weeks of work, changes allocator semantics throughout the runtime.

D. Do nothing (documented trade-off)

Ship Perry's current numbers as-is. Speed is already a win over Node. RSS gap is the cost of the arena model's simplicity. Document it, close the door.

What I'd do next

(A) looks like the right first step — "long-lived data gets its own quarantine block" is a conceptually clean, well-bounded change. Implementing that for just PARSE_KEY_CACHE + shape-cache arrays would prove the concept on the JSON workload and inform whether to extend.

References

• Closed investigation: stdlib: JSON.parse peak-RSS reduction — Perry 318 MB vs Bun 83 MB (speed gap largely closed) #149
• Block-persist origins: JSON.stringify panics on arrays of ~30k+ records with nested objects #43, JSON.parse + iterate + field access silently drops matches at scale #44
• Conservative stack scan: crates/perry-runtime/src/gc.rs mark_stack_roots
• Block-persist implementation: crates/perry-runtime/src/gc.rs:1090 mark_block_persisting_arena_objects
• Block reset: crates/perry-runtime/src/arena.rs:592 arena_reset_empty_blocks

[proggeramlug]

Closing — the headline RSS regression this issue was filed against is closed by subsequent GC + lazy-tape work.

Bench delta (bench_json_roundtrip, 50 iter × 10k records, ~1 MB blob):

	v0.5.190 (filed)	current (v0.5.313)	Bun
Median	315 ms	75 ms	259 ms
Peak RSS	318 MB	85 MB	82 MB

3.83× RSS gap vs Bun → 1.04× (effectively tied), and Perry is now 3.4× faster than Bun on this workload.

What landed since v0.5.190:

• v0.5.195 (gc: block-persistence conservatism inflates peak RSS on tight allocation loops #179 tier 1) — BLOCK_PERSIST_WINDOW = 5 (crates/perry-runtime/src/gc.rs:1804). Block-persist no longer scans old general-arena blocks, breaking the trace-to-fixed-point cascade stdlib: JSON.parse peak-RSS reduction — Perry 318 MB vs Bun 83 MB (speed gap largely closed) #149 traced (2 live blocks → 30 across 11 rounds).
• v0.5.198 (gc: block-persistence conservatism inflates peak RSS on tight allocation loops #179 follow-up) — GC trigger threshold 128 → 64 MB.
• v0.5.204+ — Lazy parse tape: output isn't materialized when the program never reads it. bench_json_roundtrip is exactly that shape.
• v0.5.221–237 — Shadow-stack precise roots, write barriers, generational GC (default ON since v0.5.237), tenuring, evacuation pass with reference rewriting. Long-lived data migrates to OLD_ARENA, so it stops anchoring general blocks for block-persist in the first place.

What this means relative to the original fix directions:

• (A) "Segregated long-lived arena region" effectively landed — the general_block_count() boundary at gc.rs:1810 is exactly that quarantine. PARSE_KEY_CACHE strings, shape-cache keys_arrays, and transition-cache arrays now live above the boundary and are kept alive by explicit root scanners (scan_parse_roots, scan_shape_cache_roots, scan_transition_cache_roots); they no longer pin general blocks.
• (C) "Generational GC" also landed (gen-gc default ON in v0.5.237 + evacuation in C4b-γ-2).

Block-persist itself still runs in both minor and major GC paths (gc.rs:1003, :1189) — the underlying mechanism is still present, just bounded by the 5-block window so it can't cascade. If the pattern resurfaces on a different workload (tight new ClassName() loops without lazy-tape coverage, large items.push({...}) build loops, etc.) we'll reopen with a fresh repro rather than carry this issue forward.