Memory not free in benchmark

[zaaack]

What happened

RSS memory grows monotonically throughout execution and never shrinks. After running a series of short-lived allocation benchmarks (arrays, Maps, Sets, strings, JSON), Perry's RSS reached 1836 MB while actual heap usage was only 164 MB. Node.js running the identical code stayed at 347 MB RSS / 122 MB heap.

What you expected

RSS should stabilize near the live-set size once temporary objects are collected.

Minimal reproduction

const ITERATIONS = 100;
const N = 100_000;

function bench(name: string, fn: () => void, iters: number) {
  for (let i = 0; i < Math.min(10, Math.floor(iters / 10)); i++) fn();
  const start = performance.now();
  for (let i = 0; i < iters; i++) fn();
  const mem = process.memoryUsage();
  console.log(`[${name}] ${(performance.now() - start).toFixed(0)}ms | rss=${(mem.rss / 1024 / 1024).toFixed(0)}MB | heap=${(mem.heapUsed / 1024 / 1024).toFixed(0)}MB`);
}

bench('array-sort-100k', () => {
  const arr = new Array<number>(N);
  for (let i = 0; i < N; i++) arr[i] = Math.random();
  arr.sort((a, b) => a - b);
}, ITERATIONS);

bench('filter-map-reduce-100k', () => {
  const arr = new Array<number>(N);
  for (let i = 0; i < N; i++) arr[i] = i;
  arr.filter(x => x % 2 === 0).map(x => x * x).reduce((acc, x) => acc + x, 0);
}, ITERATIONS * 2);

bench('map-set-get-100k', () => {
  const m = new Map<number, number>();
  for (let i = 0; i < N; i++) m.set(i, i * 2);
  let sum = 0;
  for (let i = 0; i < N; i++) sum += m.get(i) ?? 0;
  return sum;
}, ITERATIONS * 2);

bench('set-intersection-50k', () => {
  const half = N / 2;
  const a = new Set<number>();
  const b = new Set<number>();
  for (let i = 0; i < half; i++) { a.add(i); b.add(i + half); }
  const intersection = new Set<number>();
  for (const x of a) { if (b.has(x)) intersection.add(x); }
  return intersection.size;
}, ITERATIONS);

bench('string-concat-10k', () => {
  let s = '';
  for (let i = 0; i < 10_000; i++) s += 'a' + i.toString();
}, ITERATIONS);

const obj = { a: 1, b: 'foo', c: [1, 2, 3], d: { x: true } };
const jsonStr = JSON.stringify(obj);
bench('json-stringify-100', () => { for (let i = 0; i < 100; i++) JSON.stringify(obj); }, ITERATIONS * 10);
bench('json-parse-100', () => { for (let i = 0; i < 100; i++) JSON.parse(jsonStr); }, ITERATIONS * 10);

console.log('\n--- Done ---');

Command:

perry compile bench.ts && ./bench

Environment

• Perry version: 0.5.1180
• Host OS: Ubuntu 24.04.4 LTS (WSL2), kernel 6.6.87.2-microsoft-standard-WSL2
• Target: native (linux x86_64)
• Installed via: npm

Diagnostic output

Perry output:

[array-sort-100k] 3461ms | rss=102MB | heap=1MB
[filter-map-reduce-100k] 2748ms | rss=568MB | heap=4MB
[map-set-get-100k] 4308ms | rss=1343MB | heap=4MB
[set-intersection-50k] 1149ms | rss=1663MB | heap=4MB
[string-concat-10k] 161ms | rss=1749MB | heap=80MB
[json-stringify-100] 1189ms | rss=1799MB | heap=131MB
[json-parse-100] 374ms | rss=1836MB | heap=164MB

Node.js (v24.9.0) output with the same code:

[array-sort-100k] 3831ms | rss=281MB | heap=81MB
[filter-map-reduce-100k] 651ms | rss=323MB | heap=108MB
[map-set-get-100k] 2136ms | rss=361MB | heap=99MB
[set-intersection-50k] 812ms | rss=390MB | heap=147MB
[string-concat-10k] 22ms | rss=347MB | heap=100MB
[json-stringify-100] 27ms | rss=347MB | heap=106MB
[json-parse-100] 52ms | rss=347MB | heap=122MB

Heap delta per benchmark on Perry:

Benchmark	heap_delta	RSS growth
array-sort-100k	1 MB	+95 MB
filter-map-reduce-100k	4 MB	+466 MB
map-set-get-100k	4 MB	+775 MB
set-intersection-50k	4 MB	+320 MB
string-concat-10k	80 MB	+86 MB
json-stringify-100	131 MB	+50 MB
json-parse-100	164 MB	+37 MB

Heap delta is small relative to RSS growth. The GC is collecting object references, but arena blocks are not being returned to the OS.

globalThis.gc is undefined at Perry runtime, so manual GC triggers are not possible from user code.

Anything else

Tested with the following environment variables — all produce the same RSS growth pattern:

• PERRY_GC_FORCE_EVACUATE=1
• PERRY_GEN_GC=0
• PERRY_WRITE_BARRIERS=0 (compile + runtime)
• Reducing ITERATIONS from 100 to 10

Workaround: prlimit --as=4G to prevent the process from OOMing the host.

[proggeramlug]

Root-caused this. It's a real bug, and it's structural — a workload that churns large temporaries grows the old generation without bound because no collection ever runs.

Mechanism

1. Large objects bypass the nursery. arena_alloc_gc routes any allocation whose total size exceeds LARGE_OBJECT_THRESHOLD_BYTES (16 KB) straight to the old generation, born TENURED (arena_alloc_gc → arena_alloc_gc_old → OLD_ARENA). The benchmark's new Array(100_000) is an 800 KB backing buffer, so every iteration's array is born directly in old-gen and never touches Eden/survivor.

2. The benchmark triggers 0 GC cycles. Instrumenting the collector (PERRY_GC_DIAG) shows zero collections across the whole run. Because the large arrays skip the nursery, the live nursery set stays tiny (heapUsed ~1 MB), so the nursery/copying triggers never fire a completing collection. Arena::alloc does call gc_check_trigger() when it pushes a new old block, but for this allocation shape the budgeted/incremental mutator-assist path never advances a cycle to completion — so old-gen just grows monotonically (32 MB → 64 MB → …).

3. Old-gen dead blocks are only returned on a full / OldReclaim collection. reclaim_dead_old_blocks is true only for a full cycle (step_sweep, cycle.rs ~1369); a minor leaves it false. The actual return-to-OS happens in old_arena_reclaim_dead_blocks (it deallocs every dead old block except the current allocation target). Since (2) means no full cycle completes, that reclaim never runs and RSS climbs to the reporter's 1.8 GB while the live set is ~160 MB.

4. Even a forced full collection didn't reclaim old-gen in my testing. I prototyped escalating a minor → full when old-gen reclaim pressure is due (old_reclaim_pressure_due, threshold 32 MB growth / 48 MB absolute). With instrumentation the escalation fired (old_in_use=64 MB), but no old_arena_reclaim_dead_blocks call followed and RSS stayed flat — so gc_collect_full_mark_sweep_with_trigger → GcCycleState::new_full().run_to_completion() does not appear to reach the old-block reclaim on that path. That's a second, independent gap worth checking.

Fix direction

Two things need to hold for large-temporary churn to stay bounded:

• Large-object / old-gen growth must drive a completing old-gen reclaim, not just incremental mutator-assist steps that never finish when the nursery is idle. (E.g. when old_reclaim_pressure_due is true on a new-old-block allocation, run an OldReclaim cycle to completion rather than only nudging the budgeted stepper.)
• The full/OldReclaim path must actually invoke old_arena_reclaim_dead_blocks (point 4).

I stopped short of landing a fix: both touch the core collection-kind / trigger state machine (broad blast radius across every workload), and validating no pause-time / throughput regression needs the perf-benchmark suite. Flagging the precise mechanism so it can be fixed with that validation in hand. Happy to pair on it.