GC: js_regexp_new holds `&str` borrows into movable StringHeaders across its whole body (residual #7217 allocation-point witness)

[proggeramlug]

Summary

test_gap_gc_regexp_receiver_rooting still exits 139 on every allocation-point arm, 10/10 deterministic, after #7217's fix landed. #7217 turned out to be the lazy globalThis bootstrap — a different site — and closing it fixed test_gap_gc_spread_accessor_rooting and test_gap_gc_static_block_this_rooting but left this one untouched (base and fixed both exit=139, 10/10 each). So the ten regexp_receiver entries in test-parity/gc_repsel_triage.txt are retargeted here, not deleted.

Reproduction

export PERRY_RUNTIME_DIR=<build>/perry-dev PERRY_NO_AUTO_OPTIMIZE=1
perry test-files/test_gap_gc_regexp_receiver_rooting.ts -o /tmp/rx   # no compile-time env
PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off /tmp/rx
# exit=139, no output, 10/10

Clean on the safepoint route (loop_polls) and on the shipped default, exactly as #7227 claimed.

The site, named by #7196's quarantine

PERRY_GC_PROTECT_FROMSPACE=1 faults at the stale dereference (build with PERRY_DEBUG_SYMBOLS=1 for the frames):

[gc-fromspace-protect] FAULT: signal 10 at 0x27609a90064
  block=0x27609a90000 +100 retired_bytes=640 retired_by_minor=#0
  last-known object: user_ptr=0x27609a90050 obj_type=3 size=40
2  std::thread::local::LocalKey<RefCell<HashMap<(String,String), Arc<fancy_regex::Regex>>>>::with::{closure}
     (perry_runtime::regex::js_regexp_new)
3  js_regexp_new + 1396
4  main + 228

obj_type=3 is a string, and the frame is the REGEX_CACHE.with(...) closure inside js_regexp_new.

Why

crates/perry-runtime/src/regex.rs:616 opens with

let pattern_str = if is_valid_ptr(pattern) { string_as_str(pattern) } else { "" };
let raw_flags_str = if is_valid_ptr(flags) { string_as_str(flags) } else { "" };

Both are &str borrows into the heap StringHeader's payload region, and they are held for the whole function — through validate_and_canonicalize_flags, the REGEX_CACHE probe (pattern_str.to_string(), flags_str.to_string()), the validation block, get_or_compile_regex, and the RegExpHeader allocation. Every one of those is an allocation point on this route, and an evacuating minor moves the pattern string out from under the borrow.

This is the #7215 borrow shape, and the same one #7216 fixed for object_assign_string_source by taking one owned copy up front (let owned: String = s.to_string();). The &str-into-a-movable-StringHeader pattern is the family, not the individual site: string_as_str / str_bytes_from_jsvalue / js_string_key_bytes all hand out a pointer into a relocatable payload, and their own safety notes say so.

Suggested shape

Take owned copies of pattern_str / raw_flags_str before the first allocation (js_regexp_new is already O(pattern length) — it does pattern.chars().collect::<Vec<char>>() on a cache miss), or root the two StringHeaders in a RuntimeHandleScope and re-derive the slices after each allocating step. The owned copy is the one #7216 chose for the sibling and it removes the dependence on where the collection lands.

Refs #7217, #7227, #7216, #7215, #7196.

[proggeramlug]

Confirmed still open on main = d4ac65f21. Re-verified in the sweep #7262.

Compiled with no compile-time GC env, allocation-point arm:

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off \
  ./test_gap_gc_regexp_receiver_rooting
→ exit=139, no output, 10/10        (node 26.5.1: bad 0)

Unchanged from the exit=139 10/10 this issue reports at 8b024958f and with #7217's window — so #7249, #7250, #7252, #7253 and #7256 have all landed since without touching it, as expected.

crates/perry-runtime/src/regex.rs still opens js_regexp_new with string_as_str(pattern) / string_as_str(flags) and holds both &str borrows across the whole body.

Worth linking explicitly: #7215 has now been closed (its object_assign_string_source instance is fixed by #7216's owned snapshot), so this is the last open instance of that borrow family — and the family argument in #7215 ("any caller that allocates between the decode and the last use of the view has this bug, and no static gate reaches it") is now carried by this issue alone. The suggested shape there — an owned copy up front, on a path already O(pattern length) — is the same one that worked for the sibling.

[proggeramlug]

Heads-up before anyone invests here — this issue is in a class that a planned architectural change would make unrepresentable, and I don't want someone building new machinery that gets deleted.

See docs/src/internals/rfc-rooting-by-construction.md ("Where this sits in the one GC correctness plan", landed in #7292). Short version: this is layer 2 — a GC-managed pointer live in emitted machine code across a point where the collector can run. Statepoints/stack maps (#7108, #7174, enabled by #7241) would have LLVM track that liveness precisely, so the whole shape stops being expressible.

This is not "don't fix it". The architectural change is weeks away, the bug is real now, and correctness comes first — please do fix it.

It is "fix the instance, don't build new mechanism." Specifically:

• A targeted root/RuntimeHandleScope/GcSuppressScope at the site: good, lands now, survives.
• A new predicate, a new shadow-slot allocation scheme, or a new hand-maintained table deciding what to root: please raise it first. codegen: ClassExprFresh leaves the class object unrooted across its own js_object_set_field_by_name stores #7211 is the cautionary case — a four-clause predicate written by someone actively thinking about rooting, still wrong, because it asked about the user's expressions rather than the lowering's own emitted calls. Statepoints delete that entire category of judgement call.

Also worth knowing when you verify: PERRY_GC_MOVING_LOOP_POLLS=1 set at run time against a default-compiled binary is clean 10/10 and proves nothing — the poll codegen isn't in the binary. Compile-time and run-time env must both be set (#7280). And a green run that performed zero copying minors proves nothing either (#7255) — assert copied_objects > 0.