Archive — history, not state. Kept for its reasoning and its evidence; its plan is closed.
Frame-stack harvest: call frames stop being GC objects
Cherry-picked the seven-commit stack_frames lineage (two-ended actor memory block: objects grow up, mach call frames grow down as a reusable stack; captured/escaping frames promote to the heap; GC integration + tuning). Conflicts were the stacked-cherry-pick kind; shared files (runtime.c, pit_internal.h) were resolved as ours + lineage diff to preserve post-lineage branch features (boot trace, stop_watchers) and the profiling instrumentation.
Axis effects (vs 2026-07-08 profiling baseline):
| bench | before | after |
|---|---|---|
| closure_calls | 7.6ms, 10.8MB/150,017 allocs, 135 GC | 5.8ms, 2.6KB/14 allocs, 0 GC |
| text_search | 969KB/20,024 allocs, 5 GC | 8.6KB/20 allocs, 0 GC |
| record_lookup alloc | 47KB/543 | 37KB/283 |
| gc_churn GCs | 57 | 30 |
| numeric_loop ns/i | 0.66 | 0.71 (dispatch remints frame ptr; tuning commits recovered most) |
The earlier “search() allocates once per call” finding is resolved: the allocation was the C-call frame itself; frames on the stack region remove it. Runtime-services axis (carries to native): call-frame allocation is no longer a GC pressure source for any producer of mcode. Instructions dispatched are unchanged (identical mcode); wall-time gains are pure axis-3.
make check ALL GREEN (vm suite, language suite, differential fuzz); semantics probes (logic table, concat escape/alias) green; budget re-baselined.
Source: plans/archive/perf-2026-07/2026-07-08-frame-stack-harvest.md