Repository navigation
gc: REFLECT_METADATA target_bits is rekeyed with no dead-target prune #8194
Description
REFLECT_METADATA's MetadataKey.target_bits (crates/perry-runtime/src/proxy.rs) is rekeyed by rewrite_metadata_target_bits (proxy.rs:1978, visit_metadata_usize_slot) — rewritten if the target moved, deliberately not marked. Only the metadata VALUE is a strong root (visit_nanbox_f64_slot, proxy.rs:2009).
Entries are removed only by Reflect.deleteMetadata (proxy/metadata.rs:95). There is no GC death hook and no entry in gc::dead_owner's DEAD_KEY_PRUNES fan-out; the scanner's own doc (proxy.rs:1988-1990) concedes that keys go stale on a target move and only rekeys them.
That is the #8040 shape — a dead key that survives to the next cycle's rewrite_raw_addr, where recycled bytes can carry a coincidental GC_FLAG_FORWARDED. #8174 narrowed what can be followed out of such a header; it did not remove the dead key.
Second, smaller point: the guard at proxy.rs:1974 checks only the tag, so target_bits can also hold a handle-band id that is not a heap address at all. A prune must tolerate that (the dead_owner probes already skip unattributable addresses).
Fix: prune entries whose target object is dead, wired into DEAD_KEY_PRUNES (crates/perry-runtime/src/gc/dead_owner.rs).
Declared as open_gap in scripts/gc_rekeyed_key_tables.json; closing this must delete that entry, or the gate fails on the stale exemption.
Activity
fix(gc): give the six unpruned rekeyed tables a death story (#8190-#8195
proggeramlug commentedon Aug 16, 2026
Fixed in #8196.
The #8174 registry gate enumerated every
visit_metadata_*rekey site and required a written verdict for each; this table had none, and rather than declare it an exemption the prune is wired in. Its entry inscripts/gc_rekeyed_key_tables.jsonnow names a registeredDEAD_KEY_PRUNESmember, andMAX_OPEN_GAPSis 0 — the manifest ships with no declared gaps at all.Covered by a pair of cases in
gc/tests/dead_owner_side_tables.rs: the prune fires (dead owner, one collection, the table observably shrinks) and its inverse (a rooted owner's entry survives).Independent evidence that these were real stale keys and not a theoretical hazard: with only #8174's forwarding-target discriminators in place and none of these prunes, the production Next App Route forced-evacuation workload logged 988
[gc-forwarding] refused_sourcesevents — stale forwarding headers reaching a rewrite walk. With the six prunes in, the same workload logs 0 across 458 copying minors and 182,977 copied objects.fix(gc): give the six unpruned rekeyed tables a death story (#8190-#8195
fix(gc): refuse a forwarding walk out of, or into, a non-object, and …