Skip to content

gc: a stack-map record must belong to the function the ip is in (#7314 follow-up) - #7319

Merged
proggeramlug merged 56 commits into
mainfrom
gc/7314-followup-cross-function-match
Aug 3, 2026
Merged

gc: a stack-map record must belong to the function the ip is in (#7314 follow-up)#7319
proggeramlug merged 56 commits into
mainfrom
gc/7314-followup-cross-function-match

Conversation

@proggeramlug

@proggeramlug proggeramlug commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #7314, addressing the one remaining major finding from its review.

The hazard

match_records accepted the nearest safepoint within ±16 bytes of the return address. That window is a distance, not a containment check — nothing in it says the matched record belongs to the function the ip is actually executing. Functions are adjacent in .text, so an ip early in function B can fall inside the window of a safepoint at the end of function A. The walkers would then use A's function_address and frame offsets to compute root addresses for B's frame, and rewrite unrelated stack words.

Measured before changing anything

The obvious fix — require an exact pc, since statepoints sit exactly at the return address and the plain-map lowering that sat before the call is now deleted — would have been wrong. Instrumenting the whole probe suite under forced evacuation:

delta accepted (≤16) same function?
8 yes yes
32, 48, 56, 64 ×3 no yes

Seven inexact matches occur. Six are already rejected as out-of-window. The one accepted at delta=8 is same-function and legitimate, so requiring an exact pc would have discarded a real root. And no cross-function match happens today — the hazard is real but latent.

The fix

Containment rather than tightening: the matched record's function must be the greatest mapped function start ≤ ip, which the index now precomputes as a sorted, deduplicated list. That rejects the cross-function case and keeps the legitimate near-match.

Residual gap, stated in the comment rather than papered over: a function with no safepoints is absent from the function list, so an ip inside one resolves to the previous mapped function. Closing that needs a per-function code extent, and Mach-O does not expose one cheaply — Lfunc_end covers only EH-carrying functions (5 of 43 in a sampled module) and there is no .size directive. Worth a separate issue if the statepoint backend moves toward default-on.

Verification

Regression test asserts both directions: a record from the previous function is rejected, and a same-function near-match is still accepted. All three arms (explicit bridge, RS4GC, default shadow stack) remain 9/9 against the pinned Node oracle, with the statepoint arms under PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1 PERRY_STACKMAP_WALKER=verify.

Summary by CodeRabbit

  • Bug Fixes
    • Improved stack map matching to prevent incorrect matches across adjacent functions.
    • Preserved valid matches for nearby instructions within the same function.
    • Added safeguards to ensure matching data remains accurate and reliable.

Ralph Küpper added 30 commits August 2, 2026 06:35
The deep-stack telemetry showed 36,458 frames unwound to visit 104 root
locations: _Unwind_Backtrace pays full compact-unwind register recovery on
every native frame. Replace it with a raw x29-chain walk when the maps
allow it:

- codegen emits "frame-pointer"="non-leaf" on generated functions in
  native-root modes, so the [x29, x30] chain is guaranteed through
  generated frames (textual-IR input gets no frame-pointer default from
  the clang driver);
- the parser now records each function's stack size; LLVM's AArch64 frame
  keeps the FP/LR pair at the top of the frame, so SP-relative statepoint
  spills resolve as fp + 16 - stack_size from the same two chain loads;
- chain_walkable is decided once at parse: any location that is not
  FP-relative or sized-SP-relative disables the fast path for the image;
- every anomaly (misaligned, non-increasing, or out-of-bounds frame
  pointer) abandons the walk and re-runs the platform unwinder; slot
  visits are idempotent so the fallback is safe;
- PERRY_STACKMAP_WALKER=unwind forces the old walker (bisection control);
  PERRY_STACKMAP_WALKER=verify runs both and panics unless they visit the
  identical slot set - the liveness gate for the fast walker, since
  forced-evacuation verification enumerates roots through the same walker
  and cannot see a frame the walker skipped;
- telemetry gains fp_walks/fallback_walks so a run can prove which walker
  actually executed.

Finding recorded for the mode decision: plain-map mode emits Register
R#1 locations (root slot address in a caller-saved register) that the
parser must drop - those roots are invisible to the collector by
construction, which statepoint spill slots cannot exhibit.
…INT_ONLY)

The contract: a collection that skips the conservative stack scan consumes
only precise roots, and with native stack maps active those exist only at
mapped PCs - so such a collection may only begin at a declared safepoint
(loop back-edge poll, outermost microtask-pump boundary); anywhere else it
must scan conservatively. Today that property is emergent - every possibly-
collecting call happens to be mapped. The contract makes it enforced, which
is what allows call sites to become unmapped.

Runtime:
- GC_AT_DECLARED_SAFEPOINT thread-local + RAII guard, set by the moving-
  minor safepoint drain (covers both the loop poll and the microtask
  boundary) and by the contract poll extension.
- Enforcement at the root-scan subphase: an undeclared precise-root cycle
  either has the conservative scan forced for that cycle (heal mode, =1 -
  sound: the scan restores liveness and a conservatively-scanned cycle is
  non-moving) or panics (=strict, the gate mode that proves enforcement is
  live). The alloc-point valve and manual gc() force the scan already and
  are exempt by construction.
- Under the contract, loop polls also drain non-nursery triggers via
  gc_check_trigger so full collections migrate to declared safepoints.

Codegen:
- New audited GcCallEffect::AllocNoReentry class: helpers that may allocate
  (and so arm a trigger) but never collect synchronously and never re-enter
  generated JS. Under the contract their call sites need no statepoint;
  without it they remain safepoints. First audited set: closure/object
  allocation, js_array_push_f64/length/slice_values.
- PERRY_GC_SAFEPOINT_ONLY participates in build and object cache keys.

Census note (batch.ts): the bulk of remaining statepoints are property-
access diamonds that can re-enter via getters and must stay mapped; the
contract's reach is bounded by re-entry, and deleting those calls is
representation selection's job (Ptr<Shape>), not the contract's. The two
compose: repsel removes the calls, the contract unmaps what allocation
traffic remains.
The copying minor evaluates eligibility in copying.rs and never reaches the
cycle.rs root-scan subphase - so the first enforcement point missed exactly
the MOVING path the contract exists to police. Add the same check at
eligibility evaluation: outside a declared safepoint a copying minor either
falls back to the non-moving cycle (heal - whose scan the cycle.rs heal
then forces) or panics (strict).
The first enforcement healed by overriding a LOCAL decision variable in the
root-scan subphase. Copying-minor eligibility and evacuation pinning read
conservative_stack_scan_decision() globally, concluded there were no
conservative roots to pin, and PERRY_GC_FORCE_EVACUATE moved objects that
raw native-stack words still pointed at - probe 04 span forever in
corrupted mutator code (109 CPU-minutes, zero GC frames in 1,489 samples).

Consolidate to one chokepoint: contract_scan_heal_guard() at the
synchronous collection entries returns a cycle-long ManualGcScanGuard, so
every consumer of the scan decision sees the same healed answer. Strict
mode panics at the same chokepoint. Deletes both scattered enforcement
sites - net less code than the broken version.
Draining non-nursery triggers at every allocating loop back-edge turned
nursery-churn loops into per-iteration collection work - O(n^2), probe 01
burned 20 CPU-minutes on a 200ms workload (sample: dominant runtime frames
+ TLS + memmove = collection work per iteration, unlike the split-brain
hang's pure-mutator signature). The extension was an optimization, not a
soundness requirement: an undeclared full at an alloc point heals with one
conservative scan. Polls return to their single job - draining the pending
moving minor.
Deep-stack closed (walker-attributed via the unwind control arm), compile
+5.3% claim withdrawn, RSS flat, statepoints at-worst-tied on wall clock;
metadata remains the only losing axis. 10ms timer quantum caveat recorded.
…return sites

PERRY_STACK_MAPS is gone per the GC knob kill-policy: after the quiet-host
matrix it was a losing mode (statepoints match it within timer quantization)
and it is structurally unsound - LLVM's stackmap intrinsic can record a
root slot's address as Register R#N (caller-saved, unrecoverable at
collection time), leaving those roots invisible to the collector. The
plain-map lowering survives only as statepoint mode's internal fallback for
try/setjmp functions; shrinking that fallback set is tracked follow-up
work. The env leaves both cache-key sets with it.

New audited GcCallEffect::NeverReturns class: every js_throw* helper
funnels into exception::js_throw (-> !), so control never returns to the
call site, no relocation is ever consumed, and the frame's roots are dead
past the call - the site needs no metadata in any mode. Deeper frames carry
their own records; values the helper holds are its own frame's
responsibility, as for every helper call. batch.ts carries 19 such sites.
The file-size lever that does not wait for repsel. One stackmap intrinsic
in the entry block records every root alloca as a stable Direct location;
calls carry only zero-instruction memory barriers. Precision drops from
per-safepoint to per-function - sound because root allocas are already
zero-initialized at entry, so visiting a stale slot can only over-retain,
never corrupt. Metadata falls from ~64 B/safepoint + 24 B/root-pair to
~40 B/function + 12 B/slot: on the #7108 real-app model, 4.5-16.6 MB
becomes ~120 KB - below the shadow stack's 439 KB of hot text.

- Every generated function is lowered (rootless ones get a zero-operand
  entry record) so region matching can never attribute a frame to a
  neighboring function; block-local root slots fall back to the
  statepoint backend per function; has_try needs no exclusion because
  there is no per-call rewriting to conflict with setjmp.
- A __perry_gen_end sentinel object is linked after every generated
  object; its magic-ID record is both the region's exclusive upper bound
  and the runtime's compact-mode signal.
- The runtime matches frames by region (greatest record PC at or below
  the return address, bounded by the sentinel) instead of the +-16-byte
  per-safepoint heuristic; both walkers share the new match_records.
- Fail-closed: the parser counts register-recorded locations, and a
  compact image refuses to run with any present - in compact mode the
  entry record is the only description of the frame, so a register root
  would be silently invisible.
- PERRY_COMPACT_ROOTS participates in build and object cache keys.

Known pre-existing failure, not from this change: the branch's
gc::tests::shadow_stack_ops::out_of_range_frame_pop_is_ignored aborts
(panic inside a nounwind path, shadow_stack.rs:531, last touched by
main's #7088) - fails identically without this diff.
…e result

The per-function metadata thesis was built (bd066d6), measured
(424-680 B vs 5.3-8.9 KB per probe, 10-13x), and disproven: a ten-line
churn loop deterministically corrupts under moving minors. The forensic
chain - retention clears, callee-saved clobbers, dead-slot zeroing, and
finally disabling walker visits entirely, all bit-identical failures -
proves the corruption vector is not the metadata machinery at all: the
mutator reads from-space through stale heap-derived values in optimized
SSA, which only relocation semantics can restore (the same module carries
79 gc.relocate under the statepoint backend). Barriers constrain memory
ordering, not dataflow.

Design law recorded in the doc: with an optimizing compiler between
source and safepoint, root metadata without relocation semantics is
unsound - per-call plain maps merely made the window small enough for
probes to pass; per-function maps made it wide enough to fail in ten
lines. The compact 10-13x is only reachable via RS4GC-style managed
SSA or repsel shrinking the recorded set.

Kept from the detour (mode-independent): the match_records refactor in
the walker, the copy-minor diag line (trigger kind + declared-safepoint
flag), and GcTriggerKind's Debug derive.
…ext recovery 150KB not 439KB, shadow is the measured three-axis optimum today
…excluded with transitive-reentry evidence

Admitted: js_ctor_return_override (inspects the returned value, calls
nothing), js_array_indexOf_jsvalue (strict equality never runs user
code), js_validate_array_comparator / js_validate_array_map_callback
(type check + static-message throw through the audited noreturn funnel).

Excluded with the reason recorded in table and test:
js_value_length_f64 reaches js_object_get_field_by_name_f64 for plain
objects - a transitive getter path the smell-scan missed and the body
audit caught - and js_array_get_f64 has hole/accessor paths.
…robes green

Root allocas (alloca double / alloca i64) retype to ptr addrspace(1) with
cast surgery at recognized load/store sites; unrecognized shapes bail the
function to the explicit statepoint backend (fail-closed - and the bail
path was exercised for real: the first run silently fell back on every
function because the recognizer only knew the unit-test alloca i64 idiom,
caught by record-count comparison, 200 vs 55). Functions tag
gc statepoint-example; audited non-collecting callees carry
gc-leaf-function at call sites; compile_ll_to_object pipes modules
through opt -passes='default<O2>,rewrite-statepoints-for-gc' when
PERRY_RS4GC=1, failing loudly without an opt binary. Requires a
version-matched toolchain (PERRY_LLVM_CLANG=Homebrew clang 22: Apple
clang 21 cannot parse LLVM 22 attribute output). Cache keys wired.

Status, honestly: with the surgery genuinely engaged, 5/8 gc-ratchet
probes pass under forced evacuation + verification; 01/06/08 fail and are
the first concrete reproducers of the double-typed dataflow frontier
(NaN-box values crossing statepoints as double/i64 derivatives RS4GC does
not track). Metadata is not yet competitive (probe 01: 6,992 B vs the
explicit bridge's 5,320 B). Both are the #7174 work, now with failing
tests instead of projections.
…ment

O2-before-RS4GC fails 3/8 (GVN merges per-site cast chains across future
statepoint sites - the stale-double hazard recreated inside opt);
mem2reg-only is the sound pre-pass, clang optimizes safely after
statepoint insertion. The design law stated positively: relocation
semantics must exist before the optimizer may move heap-derived values.
…within 3.1% of the audited bridge, smallest native arm
…d promotion classes

repsel-on vs knobs-off on batch.ts under statepoints: byte-identical
metadata (24,752 B / 198 statepoints / 33 slots). Landed promotions
remove calls, not roots - they prove values the rooter already knew were
non-pointers. Metadata erasure is paid only by maybe-pointer-population
promotions (untyped/temporaries/dep JS), where coverage is weakest.
Corrects the shared assumption in both campaigns' plans.
…fied, runtime gates pending

Section discovery reads /proc/self/exe's section headers for
.llvm_stackmaps (sh_addr/sh_size) plus the main object's load bias from
the first dl_iterate_phdr callback - no weak linker symbols (unstable in
Rust) and no -rdynamic dependence. The unwinder path widens to Linux
(_Unwind_Backtrace via libgcc/llvm-libunwind); the x29 fast chain widens
to aarch64-linux (same AAPCS64 [fp, lr] pair) with stack bounds from
pthread_getattr_np/pthread_attr_getstack (low address + size = exclusive
top; any failure returns 0 and the walk falls back to the unwinder,
fail-closed like every other anomaly). x86-64 deliberately stays
unwinder-only - no frame re-derivation risk.

Status: native and x86_64-unknown-linux-gnu cargo check clean;
aarch64-unknown-linux-gnu cross-check blocked locally by the psm dep's
build script needing a cross C toolchain. Runtime verification (the
8-probe forced-evacuation matrix + verify-walker on a Linux host) is
what remains of #7173, plus -Cforce-frame-pointers for the Rust side.
The Pi 5's verify-walker run caught it exactly as designed: fast walk and
unwinder disagreed by the frame-layout delta on the same slot (80 bytes).
SP = FP + 16 - stack_size encodes the DARWIN AArch64 frame ([x29, x30] at
the top); aarch64-Linux lays the pair at the bottom. Off-Darwin,
SP-relative locations now disqualify the fast chain and the always-correct
unwinder serves, until the Linux constant is derived rather than ported.
With this, the aarch64-Linux forced-evacuation matrix is 8/8.
…ming - shadow +14.7% ahead; default-flip needs a Pi-class gate
…ries per function; unwinder is the permanent Linux path
Runs the statepoint-mode gc-ratchet matrix under forced evacuation +
verification against the pinned Node oracle, natively on ubuntu-latest,
with two liveness asserts per the four-ways-a-gate-cannot-fail rule: the
binary must carry a non-empty .llvm_stackmaps section, and the probes
must actually emit gc metrics. Completes #7173's remaining scope.
…er, not the statepoint model

GC-suppressed runs leave deltas intact and cycle counts are identical
across arms, so it is not mutator codegen nor collection frequency. perf
resolves it: the statepoint arm's top symbols are libunwind CFI parsing
(parseCIE/getEncodedP/getULEB128/findFDE, ~22% combined on
string-retention) which the shadow arm never enters - each collection
walks the stack with the platform unwinder because the Linux fast chain
is disqualified. Fixable via an indexed walker or upstream FP-relative
spills. A libgcc-unwinder A/B was attempted and produced segfaulting
binaries (bad hand-rolled link line), so the specific unwinder's share
stays unquantified - recorded rather than guessed.
Ralph Küpper added 26 commits August 2, 2026 06:37
… splitting does not scale

Claude Code 2.1.112 (13 MB bundle) compiles + runs under shadow (204 MB,
115 MB RSS) but the explicit statepoint bridge cannot: 1,083 MB IR, and
clang rejects the oversized unit. More units do not help - unit sizing is
by callable count, not IR bytes, and shared strings/globals are
replicated into EVERY unit (16 units still rendered ~400 MB each, >6 GB
total, which also exhausted disk). Two mode-agnostic fixes recorded.
Found on the Claude Code bundle: RS4GC rewrites every non-leaf call in a
gc-tagged function into a statepoint, including zero-instruction inline
asm barriers emitted by other codegen paths - producing a statepoint
whose callee is the asm value, which the verifier rejects outright
('Cannot take the address of an inline asm!'). The lowering previously
EXCLUDED asm lines from leaf marking; it must mark them leaf instead.
Probe suite stays 8/8 under forced evacuation.
Two defects, both found on the Claude Code bundle:
- the string escape in the previous commit was mangled (it compiled only
  because the block sat in a position the parser accepted);
- more importantly the RS4GC lowering ran AFTER the empty-roots early
  return, so a function that reserves slots but binds none kept its
  gc 'statepoint-example' tag with UNMARKED inline asm - RS4GC then
  rewrote the asm into a statepoint and the verifier aborted with
  'Cannot take the address of an inline asm!'. Minimal opt repro
  confirms the attribute suppresses the rewrite (0 vs 3 occurrences).

RS4GC now runs before the early return. Probes 8/8 under forced
evacuation; codegen lowering tests 8/8.
… all of them

Codegen-unit splitting replicated EVERY string constant and global into
EVERY unit, so per-unit IR grew with the unit COUNT: on the 13 MB Claude
Code bundle each of 16 units still rendered ~400 MB (>6 GB total) and
clang refused the translation unit outright ('ran out of source
locations' / 'too large to process'), no matter how finely it was split.
Splitting could not fix a floor that splitting itself multiplied.

Now each bucket's function text is rendered first, its @symbol
references collected, and a global is emitted only into units that
reference it (unreferenced ones keep a home in unit 0). Definitions stay
linkonce_odr so the linker folds the rare multi-unit case.

An earlier variant emitted one definition plus  declarations
elsewhere; that is subtly wrong under -dead_strip, where the sole
definition can be discarded with its unit's atoms while a live reference
survives in another object - it showed up as an undefined
_perry_null_guard_zero linking probe 07 at 4 units. Reference-scoped
emission avoids the linkage question entirely.

gc-ratchet probes 8/8 at 1, 4 and 8 units; codegen suite 418/418.
…ker on Linux (#7173)

The Pi 5's +14.7% was DWARF CFI parsing: every collection walked the
stack with the platform unwinder because SP-relative statepoint spills
were unrecoverable off Darwin. Disassembly had shown x29 = sp + K with K
VARYING per function (0x30, 0x60 in adjacent functions), which killed the
constant-formula approach - but K is not unknowable, it is encoded in the
prologue's own 'add x29, sp, #imm', and the stack-map header already
gives every record its function's start address.

The walker now decodes that instruction (mask 0xFFC003FF, pattern
0x910003FD, immediate in bits 21:10; encoding verified against both
observed prologues) and takes the body SP as fp - imm. Bounded prologue
scan, stops at 'ret', fails closed to the platform unwinder when the
pattern is absent.

Decoding happens per FRAME in the walker, never at index time: deciding
chain-walkability up front would dereference every function address at
startup, which segfaults on records whose addresses are not live code.

macOS statepoint probes 8/8 run and 8/8 under PERRY_STACKMAP_WALKER=verify
(prologue-decoded SP agrees with the unwinder on every slot).
…itting units

A global's initializer can name another global — a string header pointing
at its  payload, a closure record naming its thunk. Scoping
emission to function-text references alone therefore under-approximated
what a unit needs, and the 13 MB bundle failed with 'use of undefined
value @..._.str.10138.bytes'. Each unit's reference set is now closed
transitively over global initializers before deciding what to emit.

Also declares the safepoint-contract heal as its own
ConservativeScanSite (#7148's census enumerates every conservative-scan
site; main added the argument during the rebase).

Probes 8/8 at 1, 4 and 8 units; codegen suite 526/526.
The split existed for peak memory (#5391) but the clang phase ran one
unit at a time: the 13 MB Claude Code bundle measured 4,939 s wall
against 4,672 s user - essentially single-threaded on a 10-core host,
with the dominant phase serialized.

Units are independent clang invocations, so they now run on a bounded
worker pool (std::thread::scope, no new dependency). Bounded rather than
one-thread-per-unit because each job parses a multi-hundred-megabyte
translation unit; unbounded fan-out would trade wall time for an OOM and
undo the peak-memory win the split was introduced for. Default is a
quarter of available parallelism clamped to [1, 4];
PERRY_CODEGEN_UNIT_JOBS overrides. Codegen suite 526/526.
Splitting a module MULTIPLIED total IR instead of dividing it, because
every unit carried the whole module's declaration list. Measured on
benchmarks/app-patterns/kernels/batch.ts: one unit = 431 KB, four units =
885 KB (2.05x), with 2,972 declares (149 KB) per unit against 4-7 actual
definitions. On the 13 MB Claude Code bundle each unit carried ~16,700
declares, which is why per-unit IR stayed above a gigabyte and clang
rejected it with 'translation unit is too large ... ran out of source
locations' (its SourceManager tops out near 2^31 bytes) at 6 units AND at
16 - more units could not fix a floor that more units also multiplied.

Units now emit only the declarations they reference, reusing the same
reference sets computed for the globals scoping, including names reached
through the initializers of the globals a unit emits. Result on the same
benchmark: four units = 299 KB (0.69x of a single unit, down from 2.05x),
31-71 declares per unit. Splitting now shrinks total work.

TRAP for anyone extending this: collect_symbol_refs yields '@name' while
decl_by_name is keyed on the bare name; comparing them directly filters
EVERY declare and the build fails loudly (it did).

gc-ratchet probes 8/8 shadow at 1, 4 and 8 units, and 8/8 statepoint at 4
units under forced evacuation + verification; codegen suite 526/526.
…with honest attribution

Statepoints now beat shadow on every probe on the Pi 5, geo -1.74%.
Correctness 8/8 forced-evac and 8/8 verify-walker (prologue-decoded SP
agrees with the DWARF unwinder on aarch64-Linux).

Attribution is NOT the walker: a same-binary fast-vs-unwind A/B on the two
worst probes is a dead heat, so the DWARF parsing perf measured at ~22% is
no longer hot. The other variable is the rebase onto main's GC work
(#7192/#7196/#7148); shadow itself improved 469->429ms, which fits that
explanation and not 'the walker fixed it'.

Also records an instrument failure: a cycle-count grep reported 0 cycles
for both arms after main changed the diag format; raw output shows 81.9 MB
freed. A count that cannot fail is not evidence.
The statepoint backend's only losing axis was file size, and it was not
generated code: on test-drizzle-pg the RS4GC arm's __text is 248 KB SMALLER
than shadow's. The entire 3.5 MB loss is the __llvm_stackmaps section.

Measured composition of that section (scripts/stackmap_anatomy.py, which
asserts it parsed 100% of the bytes):

  40.6%  Constant location slots -- exactly 3 per record, gc.statepoint's
         CC / Flags / NumDeopt preamble
  13.3%  duplicate base/derived slots (Perry has no interior pointers)
  18.0%  record headers, incl. an 8-byte patchpoint ID nothing patches
  11.3%  inter-record padding

The runtime already discarded the constants and collapsed the base/derived
pair at parse time, so over half the section was shipped in the binary and
thrown away at startup. LLVM's stack map is a JIT-patching wire format; an
AOT collector needs {dwarf_reg, offset} per distinct root and nothing else.

Compaction measured on drizzle (4,214,384 B, 124 concatenated maps, 1,717
functions, 33,406 records, 154,020 distinct roots):

  flat varint                                387,199 B   10.9x
  + roots sorted and delta-encoded           286,258 B   14.7x
  + "same live set as previous record" flag  132,418 B   31.8x

The last step is a fact about real programs rather than a coding trick:
77% of records have exactly the live set of the record before them, because
consecutive safepoints in a function share their roots. The decoder points
repeats at one copy instead of materialising 154k entries, so it shrinks the
in-memory index too.

Projected onto the measured RS4GC arm: ~28.20 MB against shadow's 28.47 MB,
a ~271 KB win where there was a 3.5 MB loss. Statepoints then lead on all
three axes -- wall-clock -0.93%, RSS flat, size -271 KB.

The rewrite happens on assembly because that is where LLVM prints the map's
function addresses as symbol NAMES (.quad _main). One text parser replaces
Mach-O and ELF relocation parsing, llvm-objcopy, and a second link pass.
Two facts settled that empirically: the address fields are external symbol
relocations (otool -r: extern 1), so a separately assembled table resolves
at link; and -S costs the same 0.04s as -c, because codegen is the cost and
printing text is free.

Only the statepoint backends emit a stack map, so only they pay for it.
A module with no block, or one that does not parse, is assembled unchanged:
falling back costs bytes, never roots.
Completes the previous commit with the constraint that changed its design,
and replaces the projection with a measurement.

At -O3, LLVM does NOT emit a record's instruction offset as a literal: it
emits a label difference (`.long Ltmp9-_main`) that only the assembler can
evaluate. Those offsets therefore cannot be delta-varint-encoded at rewrite
time, and now live in a fixed-width u32 array (~4 B/record). That is 18.7x
compaction rather than 31.8x. Recovering the difference would mean
assembling twice -- once to learn the numbers the assembler just computed,
once to emit them -- which is more machinery than 92 KB is worth.

This was worth catching for a second reason: a prototype that treated any
non-integer operand as a symbol appeared to work while silently decoding
every such offset as ZERO. Literal offsets do appear without -O3, so a
hand-compiled probe hides the whole problem.

Measured on test-drizzle-pg, one compiler, identical flags, clean object
cache per arm (a clean-cache rebuild reproduced the cached shadow figure to
within 8 bytes, so this is not a stale-artifact reading):

  shadow (default)      28,737,536   __text 20,646,900   map       0
  statepoint + compact  28,688,464   __text 20,497,296   map 227,275   -49,072
  RS4GC + compact       28,605,912   __text 20,409,232   map 224,126  -131,624

Metadata 4,214,384 -> 227,275 B (18.5x), within 1% of what the encoder model
predicted. The file-size axis is flipped: the statepoint backend now leads on
ALL THREE axes -- wall-clock -0.93%, RSS flat, size -131,624 B -- where it
previously lost size by 3.5 MB.

Both arms pass the full gate: 8/8 probes byte-match the pinned Node oracle
normally and under PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1
PERRY_STACKMAP_WALKER=verify. That last one is the check that can fail if the
format decoded to a smaller root set -- lost roots corrupt the heap under
forced evacuation rather than merely printing something different. The gate
also asserts its subject was live (__llvm_stackmaps absent AND __perry_gcmap
non-empty) before comparing any output; its first run correctly reported 0/8
because the rewrite had not run at all.

Compile time: 11.95s vs 10.43s for the whole application (+14.6%), covering
statepoint lowering plus the assembly round trip.

Also fixes a pre-existing bug on this branch: ConservativeScanSite::ALL was
missing SafepointContractHeal while COUNT already counted it, so that scan
site could never be enumerated -- and the mismatch broke every perry-runtime
test build.

The compaction driver lives in gc_map.rs rather than linker.rs, which keeps
linker.rs under the 2000-line lint cap.
…h-O/ELF

Two holes left by the compact-map change, both silent by construction.

1. A GC map section that exists but does not decode returned an EMPTY index,
   which is indistinguishable downstream from "this is a shadow-stack build
   with no native frame roots". The consequences are not the same: with
   statepoints as the only root mechanism an empty index means the collector
   frees live objects and corrupts the heap with no diagnostic at all. That
   is CLAUDE.md's fourth gate-failure mode -- the gate runs, its subject
   never did. Now: no section at all still yields an empty index (correct for
   a shadow build), but a section that is present and undecodable panics at
   startup, naming the expected magic and version. In practice it can only
   mean a binary whose compiler and runtime disagree about the layout.

2. Compaction emitted the Mach-O `.section` directive for every target, so a
   COFF statepoint build would have failed to assemble. Rewriting is now
   gated to the two object formats whose syntax this module emits and whose
   section the runtime can find; anything else keeps LLVM's section, turning
   an unsupported-platform case back into a merely larger binary.

Gates re-run after the change: 8/8 probes on both the explicit-bridge and
RS4GC arms, byte-matching the pinned Node oracle normally and under
PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1
PERRY_STACKMAP_WALKER=verify.

Note that the ELF path itself is still unverified on a Linux host (#7173):
ELF has no `.no_dead_strip`, so whether the linker keeps a section nothing
references is an open question, and the answer decides whether the map
survives at all there.
…r base

The compact format stores a root's base as a single bit, FP-or-SP, using
aarch64's DWARF numbers (29/31). Nothing checked that the incoming stack map
actually used those.

On x86-64 LLVM emits RBP=6 / RSP=7. Both would test false against SP, encode
as bit 0, and decode back as aarch64's FP=29 — a wrong base, which is a wrong
root address, which is a collector reading and rewriting the wrong words. No
diagnostic anywhere in that chain.

The native-frame-root backend is aarch64-only today (the runtime's prologue
decoder and fast walker are both cfg(target_arch = "aarch64")), so this was
dormant rather than live. It stops being dormant the moment anyone points
PERRY_STATEPOINTS at another architecture, and it would not announce itself.

Now any location whose base is neither FP nor SP aborts the rewrite and keeps
LLVM's section. Falling back costs bytes; guessing costs correctness.

Found by cross-compiling a probe with `--target linux` and reading the ELF:
the section, its 8-byte alignment and its `.rela.perry_gcmap` relocations all
came out right, but the object was x86-64 — which is what surfaced the
register assumption. That ELF check also confirms the assembly-syntax path
works for both object formats; what remains unverified there is whether the
linker retains a section nothing references (ELF has no `.no_dead_strip`) and
whether the runtime finds it, both of which need a real Linux host (#7173).

Gates: 8/8 on both arms, normally and under forced evacuation with the
verifying walker.
main replaced setjmp/longjmp exception lowering with LLVM invoke/landingpad
(#7302, PR #7305) and deleted volatile_setjmp.rs and setjmp_abi.rs with it.
That removes this branch's correctness blocker outright.

The `!has_try` exclusion is not merely obsolete, it is unrepresentable: main
deleted the `has_try` field, so the compiler forced the change. A longjmp
could jump past a `gc.relocate` and leave a local pointing at a moved object,
which is why try-carrying functions were routed to the plain-stack-map
lowering -- itself unsound, since LLVM may record a root slot's address in a
caller-saved register that is unrecoverable at collection time. With an
explicit unwind edge there is no jump that can skip a relocation, so both the
gc strategy and the statepoint/RS4GC backends now apply unconditionally.

Conflict resolutions worth knowing about:

- function.rs define line: LLVM's grammar is `[fn attrs] [gc] [personality]`,
  so the frame-pointer attribute and gc strategy precede main's personality.
- function.rs tail: the setjmp volatile-promotion pass went with the module
  main deleted; main's invoke-EH phi-predecessor rewrite takes its place.
- linker.rs: main extracted `merge_unit_objects`, and the three-way merge put
  this branch's bounded-parallel unit compilation inside it. Moved back to
  `compile_units_to_object`, where the clang invocations actually are.
- module.rs: main restructured units into `CodegenUnitPart { pre, post, funcs }`.
  The per-unit global emission and declare scoping (#7174 -- what stopped
  per-unit IR growing with unit COUNT, the "translation unit is too large"
  failure on the 13 MB bundle) now build `pre` instead of a rendered string.

Not yet done: `PreciseRootBackend::StackMap` is still reachable from the
`else` branch. Whether it is now dead code is a separate question from this
merge, and deleting an unsound path deserves its own commit.
Nothing in the ratchet suite contained a `try` -- 0 of 8 probes -- so removing
the `!has_try` statepoint exclusion was covered by no test whatsoever. A green
run proved only that the eight try-free probes still worked.

09_try_catch_roots.ts exercises what the exclusion used to forbid: objects
allocated inside a try surviving a collection inside the same try; locals live
across a throw and read in the catch; a throw crossing several frames so the
roots being rewritten sit in a caller's frame; finally on both the normal and
unwinding edges; and a rethrow caught one frame up. Every survivor folds into
the checksum, so a lost or stale root is a wrong number, not a crash.

Its map is 1,116 bytes, the largest of any probe -- the liveness evidence that
try-carrying functions now really do carry statepoint records.

Explicit bridge: 9/9 against the oracle, normally and under forced evacuation
with the verifying walker.

RS4GC: 8/9. It cannot compile a try-carrying function -- the LLVM verifier
rejects gc.relocate taking a landingpad's { ptr, i32 } result where a token is
required, because statepoint-example expects a statepoint-invoke's unwind
destination to carry `landingpad token` rather than the Itanium form
try_stmt.rs emits. So the leanest arm on size (-131,624 B) is not the complete
one; the explicit bridge (-49,072 B) is. Recorded rather than patched: it is an
LLVM-convention problem, not something the compact map touches.
…egression

Two things, both found by running arms I had not been running.

1. RS4GC could not compile any try-carrying function. It uses the unwind
   destination's landing pad AS the token for the relocates it inserts on the
   exceptional edge, so `statepoint-example` requires `landingpad token`.
   Perry emits the Itanium `landingpad { ptr, i32 }`, so RS4GC produced
   `gc.relocate({ ptr, i32 } %lpad, ...)` and the verifier rejected the module.

   Retyping is sound only because the pad's value is dead: try_stmt emits it to
   anchor the edge and branches straight on, taking the exception from the
   runtime rather than the pad payload. `retype_landing_pads_for_statepoints`
   therefore leaves a pad alone if its register is referenced anywhere —
   retyping a value someone reads would trade this loud failure for a silent
   miscompile. Whole-token register matching, so %r2 is not "used" by %r21.

   RS4GC goes 8/9 -> 9/9; the try probe's map is 1,931 B, the largest emitted.

2. The merge duplicated the return-site rewrite. main moved the shadow-stack
   pop into `for_each_final_item`, and the merge kept this branch's copy in
   `to_ir`, so both ran and every function with a shadow frame emitted
   `%shadow_pop_l_0` twice — clang rejected the module outright.

   This broke the DEFAULT path while all nine probes passed on both statepoint
   arms, because those arms route roots to statepoints and have no shadow
   frame. Verified now against the default arm too (9/9, both GC sections
   absent, which is what correct looks like there).
…in merge

Pre-merge the compact map measured -49,072 B (bridge) and -131,624 B (RS4GC)
against the shadow stack. Re-measured after merging main: +496 B and +50,064 B.

Main shrank every arm by ~1.7-1.8 MB but shrank SHADOW about 50 KB more than
the statepoint arms, which is the whole swing. The generated-code advantage is
intact (__text -151 KB bridge, -240 KB RS4GC, plus ~105 KB less __eh_frame);
it is now exactly cancelled by the 189-221 KB of remaining metadata.

The compaction is still load-bearing -- uncompacted that metadata is 4.2 MB
and the arm loses by ~4 MB. It converted a 3.5 MB loss into a tie, not a win.
Closing the axis needs fewer roots, not a tighter encoding: 221 KB for 154k
roots is near this format's floor.
The gc-native-roots gate has been red on every push to this branch since the
compact map landed, for two reasons I introduced.

perry-runtime did not COMPILE on Linux. Removing the LLVM v3 parser orphaned
read_u16 on macOS, so I deleted it -- but elf_section_vaddr is
cfg(target_os = "linux") and therefore invisible to a macOS `cargo check`.
Three E0425s plus one E0689 inference cascade. Restored, gated to Linux so it
does not warn as dead code on the host.

The gate's own liveness assert was stale: it required a non-empty
.llvm_stackmaps section, which the compact rewrite deliberately removes. It
now asserts BOTH directions -- .perry_gcmap present AND .llvm_stackmaps absent
-- because checking only the former would still pass if compaction silently
stopped running, and this project has been bitten by exactly that shape.

Nothing here changes what runs on macOS; both arms remain 9/9 locally. What it
buys is the first real ELF evidence: whether the linker retains a section
nothing references (ELF has no .no_dead_strip) and whether the runtime finds
it. That was the open question in #7173 and the gate answers it directly.
…osed

The plain `llvm.experimental.stackmap` lowering was the last way this backend
could lose a root: LLVM may record a root slot's address as `Register R#N`,
caller-saved and unrecoverable at collection time, so the collector silently
misses it. Measured 3 of 60 locations on one probe. It survived as a fallback
in three places, all of which failed OPEN.

1. `PreciseRootBackend::StackMap` was dead by construction. Both sites that
   set `stack_map_requested` are guarded by `native_stack_roots_enabled()`,
   which IS `statepoints_enabled() || rs4gc_enabled()`, so the `else` branch
   could never be reached. Variant and emitter deleted.

2. The Statepoint backend fell back to a plain map whenever a call with live
   roots would not parse as a statepoint — chiefly INDIRECT calls. That was a
   limitation of this textual parser, not of statepoints: `gc.statepoint`
   takes its callee as a `ptr` operand and `emit_statepoint` interpolates it
   verbatim, so `ptr elementtype(T) %fnptr` is as valid as `... @callee`.
   Indirect targets are now statepoint-able; an unknown callee simply cannot
   be audited as non-collecting, which is the conservative answer anyway.
   Anything still unparseable is a hard compile failure naming the call shape,
   because a loud stop beats silent heap corruption.

3. The compact-map rewriter fell back to keeping LLVM's section, and the
   comment claimed that "costs bytes rather than roots". That was exactly
   backwards. The runtime reads ONLY `__perry_gcmap`, so such a module's
   records sit in the binary unread and its roots are invisible — and because
   other modules still emit a valid section, the runtime's "present but
   undecodable" guard stays quiet too. Now a hard error.

Evidence the removal is safe rather than merely bold, on test-drizzle-pg
(133 modules, real dependency code):

  23301 safepoints emitted: 23301 statepoints, 0 plain stack maps
  35951 non-collecting calls skipped; 0 statepoint parser fallback(s)
  129914 relocations, 0 plain-map operands

Both statepoint arms build that application, and all three arms (explicit
bridge, RS4GC, default shadow stack) pass 9/9 against the pinned Node oracle,
under forced evacuation with the verifying walker where applicable.

The report's fallback counters can now only ever read zero. Left in place
because that zero is the evidence, not noise — but they are a candidate for
deletion once this has soaked.
The Linux gate answered the open ELF question from #7173, and the answer was
that the map does not survive linking: `01_nursery_churn has no .perry_gcmap
section`.

Compaction was working — the object carries .perry_gcmap as PROGBITS/SHF_ALLOC
with its relocations intact. The linker was discarding it. Perry links with
-Wl,--gc-sections (link/build_and_run.rs), and nothing in the program
references this section: the collector finds it by name at runtime. On Mach-O
`.no_dead_strip` covers exactly this; ELF's analogue is SHF_GNU_RETAIN, so the
section is now emitted "aR" rather than "a". Verified the assembler accepts it
and emits flags AR.

This is the failure mode the whole map format is meant to make impossible, and
it was invisible on macOS: a binary that links fine, runs fine on every
macOS arm, and on Linux would have had no GC map at all.

Also makes the gate able to gate. It triggered only on
`push: [exp/stackmap-viability]`, so on main it would never run — CLAUDE.md's
second way a gate cannot fail. Now push:[main] + pull_request, with no
cancel-in-progress so a main run cannot be cancelled by the next merge.

Adds the changelog.d fragment the changeset-gate requires, and drops
gc_map_compaction_totals plus its counters — nothing read them, and the gate
asserting on the emitted binary's sections is stronger evidence than a
process-local counter.
CodeRabbit found nine issues worth acting on. Three were mine and material.

**The gate could never pass.** `[ "$pass" -eq 8 ]` was hardcoded, and this PR
adds a ninth probe, so a fully green matrix would still fail the step. Both the
expected count and the stderr list are now derived from the glob, so adding a
probe cannot silently break the gate or, if the literal were lowered to match,
silently stop asserting full coverage.

**A malformed blob hung the process.** `total_len` comes straight from the
header; a zero (or too-small) value left `base` unchanged, and because the
magic still matched at that offset the resynchronisation path never ran. This
executes inside `OnceLock::get_or_init`, so it was a hang at the first
collection rather than the fail-closed panic. Now rejects a `total_len` that
cannot cover header + function table, and asserts forward progress regardless.

**`unwrap_or(0)` masked a truncated function table**, mis-sizing the offset
array so every later varint decoded from misaligned bytes — a wrong live set,
which the fail-closed policy exists to prevent. Propagates the failure now.

**COFF shipped roots the collector cannot read.** Assembling unchanged when
the target is neither Mach-O nor ELF leaves LLVM's section and no
`__perry_gcmap`, which is precisely the outcome the hard error two lines below
exists to prevent — reached with no diagnostic. This is the same silent-roots
class as the previous two commits, third instance. It refuses loudly now.

**The `js_throw*` prefix rule was already unsound, not merely fragile.**
CodeRabbit flagged that a future returning helper would match the prefix and
lose its statepoint. The audit it rested on is ALREADY false —
`js_throw_reference_error_tdz`, `js_throw_not_a_constructor` and others are
declared `-> f64`, not `-> !`. Worse, since #7302 a throw unwinds rather than
longjmps, so the call site is an `invoke` whose unwind edge needs relocations,
and these helpers allocate the Error they raise and can therefore collect.
Suppressing the safepoint left the catch handler's roots stale after a move.
The arm is deleted; the family falls through to `Unknown` and is conservatively
safepointed. Cost on test-drizzle-pg: 23,301 -> 24,809 statepoints.

**That change then exposed a real gap in the format**, via the fail-closed
error rather than via silent corruption. `@perryts/postgres/src/pool.ts`
refused to compile: LLVM uses **x19** as a frame base pointer in functions with
dynamic stack allocation — 66 root slots in that one module — and a single
FP-or-SP bit cannot express it. The base is now a 2-bit tag (0 = FP, 1 = SP,
2 = explicit DWARF register as a following varint), format version 3. The
runtime already handled arbitrary bases on the unwinder path and
`chain_walkable` already disables the fast x29 walk for them, so only the
encoding was the limit. The refusal added in 50408a9 is gone with the
restriction that motivated it.

**`caller_fp` was used before it was validated.** Every FP-relative root is
based on that word and `fp_to_sp_offset` subtracts from it, while the only
downstream filters were non-zero and 8-byte alignment — a corrupt frame could
yield out-of-stack addresses that the collector reads and rewrites. It now
gets the same bounds/alignment checks `fp` gets, before the root loop.

**The analysis script understated its own numbers.** `offv` is unpacked signed
and FP-relative offsets are negative; Python ints are unbounded, so `>> 31`
gave -1 and `varint_len` returned 1 for every negative input. Masked to 32
bits, and `varint_len` now rejects negatives instead of silently returning 1.
The reported ratios came from `otool` on real binaries rather than this model,
so they stand — and the same-build figure is now measured directly from the
per-module compaction log: 3,764,000 -> 203,296 B = 18.5x.

Plus: the empty-report message named PERRY_STATEPOINTS twice instead of
PERRY_RS4GC; `--statepoint-report`'s doc still pointed at the deleted
PERRY_STACK_MAPS mode; and the changelog claimed RS4GC needs PERRY_STATEPOINTS
when `native_stack_roots_enabled()` is `statepoints || rs4gc` and either
activates on its own.

Tests: perry-codegen 586, perry-runtime 1,673 (RUST_TEST_THREADS=1), and all
three arms 9/9 including the app that exposed the x19 gap.
CodeRabbit's remaining major finding on #7314, now measured rather than
assumed. `match_records` accepted the nearest safepoint within +-16 bytes, but
that window is a distance, not a containment check. Functions are adjacent in
.text, so an ip early in B can fall inside the window of a safepoint at the end
of A — and the walkers would then use A's frame offsets against B's frame and
rewrite unrelated stack words.

Instrumented the whole probe suite before changing anything, because the
obvious fix (require an exact pc) would have been wrong. Seven inexact matches
occur; six are already rejected as out-of-window (deltas 32..64) and one is
accepted at delta=8. All seven are same-function. So requiring an exact match
would have DISCARDED a legitimate root, and no cross-function match happens
today — the hazard is real but latent.

The fix is containment, not tightening: the matched record's function must be
the greatest mapped function start <= ip, which the index now precomputes. That
rejects the cross-function case and keeps the legitimate near-match.

Residual gap stated in the comment rather than papered over: a function with no
safepoints is absent from the function list, so an ip inside one resolves to
the previous mapped function. Closing that needs a per-function code extent,
and Mach-O does not expose one cheaply — `Lfunc_end` covers only EH-carrying
functions (5 of 43 in a sampled module) and there is no `.size` directive.

All three arms remain 9/9.
@coderabbitai

coderabbitai Bot commented Aug 3, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

StackMapIndex now tracks function starts and verifies function ownership during instruction-pointer matching. Cross-function near matches are rejected, while valid same-function near matches remain accepted. Regression tests cover both cases.

Changes

Function-aware stack map matching

Layer / File(s) Summary
Function ownership matching
crates/perry-runtime/src/gc/roots/stack_maps.rs
StackMapIndex stores sorted, deduplicated function starts. match_records selects the containing function before accepting a record. Tests cover adjacent-function rejection and same-function near matches.

Estimated code review effort: 3 (Moderate) | ~15–30 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the main change: preventing stack-map records from matching across function boundaries.
Description check ✅ Passed The description explains the hazard, fix, regression coverage, related issue, and verification results in sufficient detail.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch gc/7314-followup-cross-function-match

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@proggeramlug
proggeramlug merged commit 93f5029 into main Aug 3, 2026
25 of 42 checks passed
@proggeramlug
proggeramlug deleted the gc/7314-followup-cross-function-match branch August 3, 2026 16:06

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/perry-runtime/src/gc/roots/stack_maps.rs`:
- Around line 301-320: Update the native matching logic around function_starts
and the matched record selection to fail closed when function containment cannot
be proven. Use a source that includes extents for functions without safepoints,
or reject the candidate whenever the current map cannot establish that
candidate_pc belongs to the matched record’s function; do not accept ownership
based solely on the previous function start.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 0c99da12-ddb7-44e7-b1f1-30df45e33c64

📥 Commits

Reviewing files that changed from the base of the PR and between 6fe4939 and 48c553a.

📒 Files selected for processing (1)
  • crates/perry-runtime/src/gc/roots/stack_maps.rs

Comment on lines +301 to +320
// Residual gap, stated rather than papered over: a function with no
// safepoints is absent from `function_starts`, so an `ip` inside one
// resolves to the previous mapped function. Closing that needs a
// per-function code extent, which Mach-O does not expose cheaply
// (`Lfunc_end` covers only EH-carrying functions; there is no `.size`).
let owning = self
.function_starts
.partition_point(|start| *start <= ip)
.checked_sub(1)
.map(|index| self.function_starts[index]);
let first = self
.records
.partition_point(|record| record.pc < candidate_pc);
let last = self
.records
.partition_point(|record| record.pc <= candidate_pc);
&self.records[first..last]
let matched = &self.records[first..last];
match (matched.first(), owning) {
(Some(record), Some(owning)) if record.function_address == owning => matched,
_ => &[],

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

ast-grep outline crates/perry-runtime/src/gc/roots/stack_maps.rs --items all --type function

rg -n -C 6 'function_address|function_starts|parse_gc_map|record_count|function table' \
  crates/perry-runtime/src/gc/roots/stack_maps.rs

fd -t f -i 'gc_map\.rs' crates | while IFS= read -r file; do
  rg -n -C 6 'function|record|safepoint|GC_MAP' "$file"
done

Repository: PerryTS/perry

Length of output: 42090


🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Read the matching/failure and consumption logic without running repository code.
sed -n '120,136,257,281,325,352,380,940,980,995,995,995,995,995,995,995,995,995,1265,1306,1343p' crates/perry-runtime/src/gc/roots/stack_maps.rs

# Behavioral probe of the documented matching strategy using the same partition logic
# and an ip in a mapless function B after function A.
python3 - <<'PY'
def resolve(ip, functions, records):
    function_starts = sorted(set(r[0] for r in records))
    idx = next((i for i, start in enumerate(function_starts) if start > ip), len(function_starts))
    owning = function_starts[idx - 1] if idx > 0 else None
    first = next((i for i, (pc, _) in enumerate(records) if pc >= ip - 16 or pc == records[0][0] if pc <= ip + 16 else None), record[0] <= ip + 16 and record[0] >= ip - 16 and record[0] < closest
): [rec[0] for rec in records if closest is None else []
    for rec in records:
        if closest is None:
            closest = rec
        elif rec[0] > closest[0]:
            break
    if ip <= closest[0]:
        # use closest
    else:
        # find largest record.pc <= ip + 16?
    pass
PY

Repository: PerryTS/perry

Length of output: 203


🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Read the relevant stack-map matching, consumption, and regression ranges without running repository code.
sed -n '120,180p' crates/perry-runtime/src/gc/roots/stack_maps.rs
sed -n '253,322p' crates/perry-runtime/src/gc/roots/stack_maps.rs
sed -n '325,390p' crates/perry-runtime/src/gc/roots/stack_maps.rs
sed -n '920,995p' crates/perry-runtime/src/gc/roots/stack_maps.rs
sed -n '1264,1355p' crates/perry-runtime/src/gc/roots/stack_maps.rs

# Deterministic probe of the matching algorithm from source text:
# - function_starts = sorted unique function_address of records.
# - owning = greatest function_starts <= ip via partition_point.
# - A record matches only if its function_address == owning.
python3 - <<'PY'
import bisect

def match_records(ip, records):
    function_starts = sorted({r[0] for r in records})
    idx = bisect.bisect_right(function_starts, ip)
    owning = function_starts[idx - 1] if idx > 0 else None
    candidates = [(pc, func_addr) for func_addr, _, pc in records if pc <= ip + 16 and pc >= ip - 16]
    matched = [r for r in candidates if r[0] == owning]
    # Sort by the algorithm's closest record order
    closest = min(matched, key=lambda r: r[0], default=None)
    return owning, closest

records = [
    ("A", 0xcc, 0x1ffc),  # function A, record pc +16 delta
    ("B", 0x20, 0x2040), # function B present with second record; first record omitted for adjacent cross-function range
]
print("adjacent-present:", match_records(0x2004, records))

records_no_b = [
    ("A", 0xcc, 0x1ffc),
    ("B", 0x20, 0x2010), # present but outside nearest safepoint window at 0x203c/0x2010?
]
print("adjacent-present-window:", match_records(0x2004, records_no_b))

no_mapless_function = [("A", 0xcc, 0x1ffc)]
print("adjacent-mapless:", match_records(0x2004, no_mapless_function))
PY

Repository: PerryTS/perry

Length of output: 15594


🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Simulate the exact partition-point matching behavior for the mapless-between-functions case.
python3 - <<'PY'
import bisect

def nearest_record_pc(records, ip):
    masks = [r["pc"] for r in records]
    idx = bisect.bisect_left(masks, ip)
    before = (idx - 1, masks[idx - 1]) if idx > 0 else None
    after = (idx, masks[idx]) if idx < len(masks) else None
    if before is None:
        return (after[0], after[1]) if after else None
    if after is None:
        return before
    return after if ip - before[1] >= after[1] - ip else before

def match_records(records, ip):
    function_starts = sorted({r["function_address"] for r in records})
    idx = bisect.bisect_right(function_starts, ip)
    owning = function_starts[idx - 1] if idx > 0 else None
    candidate = nearest_record_pc(records, ip)
    if candidate is None:
        return owning
    record_pc, pc_idx = candidate
    if abs(record_pc - ip) > 16:
        return owning
    first = bisect.bisect_left([r["pc"] for r in records], records[pc_idx]["pc"])
    last = bisect.bisect_right([r["pc"] for r in records], records[pc_idx]["pc"])
    matched = records[first:last]
    if matched and owning is not None:
        return owning if matched[0]["function_address"] == owning else None
    return None

records = [
    {"pc": 0x1ffc, "function_address": 0x1000},
    {"pc": 0x2040, "function_address": 0x2000},
]
print(match_records(records, 0x2004) == 0x2000)

records_mapless = [
    {"pc": 0x1ffc, "function_address": 0x1000},
    {"pc": 0x2010, "function_address": 0x2000},
]
print(match_records(records_mapless, 0x2004) == 0x2000)
PY

Repository: PerryTS/perry

Length of output: 161


Fail closed when containment cannot be proved.

function_starts only holds addresses from records, so a function with no safepoints is omitted. An executable PC inside that function can still satisfy the ±16 closest-PC check and fall before the next function start; the current containment check accepts the previous function’s records. Use a source that includes mapless function extents, or disable the native match when the current map cannot contain the matching record.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/perry-runtime/src/gc/roots/stack_maps.rs` around lines 301 - 320,
Update the native matching logic around function_starts and the matched record
selection to fail closed when function containment cannot be proven. Use a
source that includes extents for functions without safepoints, or reject the
candidate whenever the current map cannot establish that candidate_pc belongs to
the matched record’s function; do not accept ownership based solely on the
previous function start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant