fix(interp): stop host allocation scanning the heap and leaking frame slots - #171

Two defects landed together with the heap-ownership rework and made
allocation-heavy guest programs regress badly (#169, #170).

owner() answered "is this pointer already in a heap slot?" by scanning
every live slot with reflect.ValueOf().Pointer(). It runs on Alloc,
Store, and Push, so an embedder that allocates once per guest operation
paid O(heap) per allocation and ran quadratically: a fannkuch-redux
program that took 6.1s stopped finishing inside 45s. Replace the scan
with an index keyed by the value itself. Only the host boundary records
hints, so the interpreter's own allocation path is untouched, and lookup
validates against the heap, so a hint left by a freed or reused slot
self-heals instead of needing removal bookkeeping on release and sweep.
A prune pass bounds the index and doubles the budget it survives, which
keeps upkeep amortized constant.

RETURN moved the returned values down and truncated the stack without
releasing the params, locals, and operands it discarded, so every call
that received a reference leaked one count. land already releases those
slots when an exception unwinds a frame; RETURN now does the same.
Reference counting had leaked this way before, but the old root-based
mark and sweep reclaimed it; trial deletion reads an inflated count as
ownership outside the heap and cannot, so the leak became unbounded.
Frames whose every slot is a plain scalar skip the sweep when their
operand stack is balanced, which keeps scalar recursion close to its
former cost.

Measured with the reporter's program corpus on linux/amd64 (min of
three): fannkuch 6.9s where it previously did not finish, binarytrees
1.60s against 1.80s before the regression window, and the unrelated
kernels unchanged. RecursiveFib(20)/threaded costs 604 -> 625 ns/op for
the exact counts.

Adds vm_gc_cycles_total and vm_gc_slots_total so collector pressure is
observable, a heap-exhaustion regression test that fails without the
RETURN fix, and two builder-based benchmarks covering the reported
shapes with no external dependency.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017ZsuY2FrrwQ7S3PGw98RQh

Summary by CodeRabbit

• Performance

  • Improved memory-management performance for recursive workloads and host-integrated operations.
  • Reduced unnecessary cleanup work during routine execution and returns.

• Bug Fixes

  • Improved frame cleanup to prevent retained references from exhausting available memory.
  • Strengthened pointer ownership handling and garbage-collection reliability.

• Documentation

  • Added guidance for heap ownership, return-value memory behavior, and garbage-collection metrics.
  • Expanded benchmark coverage and documented new memory-related results.

• Monitoring

  • Added metrics for total garbage-collection cycles and processed heap slots.