Three perry-runtime tests flake under parallel test runs (reproduce on unmodified main)

[proggeramlug]

Three perry-runtime lib tests fail intermittently when the suite runs in parallel (the default). They have cost four gate runs across three PRs today, each time looking like the PR's fault:

• gc::roots::stack_maps::decode_tests::tests::discovers_a_map_from_a_later_loaded_shared_object — the consistent offender; it dlopens a shared object
• r#box::release_tests::completed_activation_residue_is_bounded_not_linear
• symbol::get::own_data_ic_tests::composed_symbol_field_cache_reloads_mutated_final_slot

Evidence that it is not the change under test

• The failing set changes between runs of the same commit. Two gate runs on one commit reported 2818 passed; 2 failed each, with a different second test.
• All three pass single-threaded, on the branch and on origin/main: cargo test --release -p perry-runtime --lib -- --test-threads=1 <names> → 3 passed.
• Unmodified origin/main reproduces it. Three parallel runs of cargo test --release -p perry-runtime --lib on main: runs 1 and 2 green, run 3 2819 passed; 1 failed on discovers_a_map_from_a_later_loaded_shared_object.
• Load is not the trigger. It first appeared with the box at load 12–15, but also flaked at load 1.0, so these are racy in parallel rather than merely timing-sensitive under contention.
• The PRs where it surfaced (perf(codegen): packed clones read a foreign counter inline (10_nested_loops 51 → 17 ms, Node parity) #9161, perf(codegen): a fixed-size allocation expression keeps the buffer-view tier (bench_int_arithmetic 395 → 149 ms) #9181, perf(codegen): an indexed store skips the addref for a provably non-string value #9195) touch perry-codegen only.

Why it is worth fixing rather than re-running

The failure is indistinguishable at a glance from a real regression, so every occurrence costs someone a bisect-or-believe decision — and the cheap resolution ("just re-run") is exactly the habit that hides a genuine flaky-looking regression later.

Shapes worth considering: a shared-object load and a symbol-registry/IC cache are both process-global, so parallel tests contend on state that is not per-test. Serializing these three (a mutex, serial_test, or a --test-threads=1 lane for the modules that touch process-global registries) would remove the ambiguity.

https://claude.ai/code/session_012Ys25ni6VwDKE71o1NTYAT