GC: a class expression with a `static { … }` block SIGSEGVs under PERRY_GC_MOVING_LOOP_POLLS=1 (static-`this` cell is not a rewritten root)

[proggeramlug]

Summary

A class expression carrying a static { … } block SIGSEGVs (exit=139) under PERRY_GC_MOVING_LOOP_POLLS=1 when the block's body allocates. Clean under the shipped default. A variant that captures an outer value does not crash but computes the wrong static value 4 times in 400.

This is a residual site of the #7154 class that #7192 did not close, and a hard blocker for reverting #7161.

Reproducer

function churn(): number {
  const a: any[] = [];
  for (let i = 0; i < 600; i++) a.push({ i: i, s: "q" });
  return a.length;
}
function make(): any {
  return class {
    static k: number = 1;
    static {
      (this as any).viaBlock = churn();
    }
  };
}
let bad = 0;
for (let r = 0; r < 400; r++) {
  const C: any = make();
  if (C.k !== 1) bad++;
  if (C.viaBlock !== 600) bad++;
}
console.log("bad", bad);

node --experimental-strip-types  →  bad 0
perry, default                   →  bad 0
perry, PERRY_GC_MOVING_LOOP_POLLS=1 (compile AND run)  →  exit=139, no output

Reproduced identically at 73a9084ea, so inherited, not caused by #7184/#7192.

A capturing variant (make(tag) with churn() + tag) does not crash and reports viaBlock 4 wrong out of 400 — that one already pushed a root before #7198 via the !captured_args.is_empty() clause, which is the evidence that the class object is not the stale thing here.

Where it is

Not the class object. #7198 adds !block_fns.is_empty() to Expr::ClassExprFresh's protection predicate, and the emitted IR confirms the object is now temp-rooted at allocation and re-read before every use:

%r18 = call i64 @js_object_alloc(i32 3, i32 1)
call void @js_object_mark_class(i64 %r18)
call void @js_class_object_pin_parent(i64 %r18, i32 3)
%r19 = call i32 @js_gc_temp_root_push(i64 %r18)
...
%r33 = call i64 @js_gc_temp_root_get(i32 %r19)      ; re-read before arming
%r35 = <nanbox %r33>
call void @js_static_this_arm_value(double %r35)
%r36 = call double @perry_static_..._init_0()        ; the block body — user code
%r37 = call i64 @js_gc_temp_root_get(i32 %r19)      ; re-read after

The crash survives that. What is still stale is the value js_static_this_arm_value parks in the runtime's one-shot static-this cell: the compiled block body reads it back through js_static_this_resolve, and if the object relocates between the arm and the resolve — or between the resolve and the body's this.x = … stores — the cell hands out a from-space address. That cell needs to be a registered, rewritten root (mark and rewrite, like RuntimeHandleScope at gc/roots/runtime_handles.rs:258-275), not a plain thread-local word.

crates/perry-runtime/src/object/... js_static_this_arm_value / js_static_this_resolve are the entry points.

Why it matters

Until this is closed, PERRY_GC_MOVING_LOOP_POLLS=1 cannot become the default again — #7161 cannot be reverted and #7019's minor-GC RSS win stays reverted.

Refs #7154, #7161, #7192, #685.

[proggeramlug]

Fixed in #7207 — but not where this issue says.

STATIC_THIS_OVERRIDE (object/this_binding.rs:38) is already a marked-and-rewritten root: scan_implicit_this_roots_mut visits it at this_binding.rs:212-217 with visit_nanbox_u64_slot (which marks and writes back) and is registered at gc/mod.rs:523. The static-block body's this alloca is shadow-bound too — codegen/method.rs:1385-1390 binds the extra slot enable_shadow_frame(m.len() + 1) reserves. "Make the cell a registered, rewritten root" would have been a no-op.

The emitted IR names the real one. (this as any).viaBlock = churn() lowers through the #6812 dynamic-key write IC:

%r9  = load double, ptr @…_.str.2.handle      ; the KEY literal — loaded ABOVE the call
%r10 = call double @perry_fn_…__churn()        ; user code -> back-edge poll -> evacuating minor
%r11 = load double, ptr %r7                    ; `this` re-read — correct
%r12 = bitcast double %r9 to i64               ; the STALE key
…
put.dynic.slow.7:
  %r99 = call double @js_put_value_set_dyn_ic(ptr @perry_ic_8, double %r11, double %r9, …)

The comment at that lowering claimed the path was "GC-clean with NO compile-time value gate … a moved key merely misses by stale bits (identity compare — false negatives only)". True of the three way-compares; false of everything below them. The miss falls through to put.dynic.slow, which hands the same register to js_put_value_set_dyn_ic, which dereferences it as a StringHeader*. A string literal's __perry_init_strings_* handle is a registered root that evacuation rewrites — #7114 exactly — so the register loaded above churn() names from-space.

An identity-compare-only use is not the only use.

test-files/test_gap_gc_static_block_this_rooting.ts, compiled and run with PERRY_GC_MOVING_LOOP_POLLS=1: bad 4 at origin/main (3a983ca6a), deterministic 3/3 → bad 0 5/5 with the fix, clean 3/3 under the shipped default, byte-exact vs Node 26.5.1.

[proggeramlug]

Re-verified on main = d4ac65f21. Fixed — closing.

Fixed by #7207 plus #7249 (64c1f56fb).

This issue's diagnosis was wrong and #7207 corrected it in the tree — worth restating here so it does not get re-derived. The static-this cell is a red herring: STATIC_THIS_OVERRIDE (object/this_binding.rs:38) is already both marked and rewritten by scan_implicit_this_roots_mut, and the static-block body's this alloca is shadow-bound at codegen/method.rs:1385. What was actually stale was the key of (this as any).viaBlock = churn(): the #6812 dynamic-key write IC lowers k → v → t, and the in-tree comment claiming a moved key "merely misses by stale bits (identity compare — false negatives only)" was true of the three way-compares and false of the slow path below them, which hands the same register to js_put_value_set_dyn_ic and dereferences it as a StringHeader*.

Evidence

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_static_block_this_rooting

	result
this issue's report	exit=139 / bad 1, 10/10
d4ac65f21	bad 0, 10/10, byte-exact vs node 26.5.1

Movement confirmed on the same binary and arm: 5 copying minors, 17 364 objects copied.

Part of the sweep in #7262.