addr_class heap window [2TB,128TB) assumes mimalloc mappings — system-allocator runtime builds silently misclassify all heap pointers

[proggeramlug]

Found while validating PR #6917's size mode. Building perry-runtime with std::alloc::System instead of mimalloc (the new alloc-mimalloc feature off) produces binaries that misbehave silently:

• console.log("x") prints nothing, exit 0
• heavier programs throw spurious empty-message TypeErrors

Root cause: value/addr_class.rs classifies a NaN-boxed payload as a dereferenceable heap pointer only inside [0x200_0000_0000, 0x8000_0000_0000) — i.e. [2 TB, 128 TB). That window encodes mimalloc's macOS mapping range (3-5 TB). macOS system-malloc allocations land far below 2 TB, so with the system allocator every string/object allocation fails is_plausible_heap_addr and is treated as a handle/non-pointer.

Repro: build any program with the auto-optimize rebuild passing --no-default-features --features perry-runtime/full (i.e. without alloc-mimalloc) and run it. Identical build with alloc-mimalloc behaves correctly (verified both ways on macOS arm64, -Oz archives).

PR #6917 sidesteps this by force-adding alloc-mimalloc on every auto-optimize rebuild; the cfg gate remains in place. To actually offer a system-allocator build (~140 KB smaller, and a prerequisite for allocator flexibility on new targets), the heap-window predicates need an audit:

• is_valid_obj_ptr / is_plausible_heap_addr bounds per (OS, allocator)
• every other magnitude test that assumes the 2 TB floor (grep for 0x200_0000_0000 and the "3-5 TB" comments in array/header.rs, symbol.rs, map.rs, set.rs)
• Linux implications: memory of prior issues says small system-malloc addresses are exactly the class that SIGSEGVed Linux-only before (fix(runtime): guard native-module deref against the small-handle band (Linux SIGSEGV in zlib streams) #6271 family) — the same audit should cover it

Related: the existing handle-band work (addr_class::is_plausible_heap_addr is the canonical predicate per repo policy).

[proggeramlug]

The named root cause is factually wrong, but the symptom you reported is real — leaving this open for that reason.

value/addr_class.rs sets HEAP_MIN = 0x1000 on macos/linux/windows/android/ios/tvos/watchos/visionos; the 2 TB floor survives only for unlisted targets. array/header.rs's clean_arr_ptr is identical. Both predate this issue (#4899 / #1136), so "the heap window assumes mimalloc mappings" does not describe current macOS behaviour.

What is still unexplained is the observed failure: console.log printing nothing under std::alloc::System. That wants a fresh diagnosis rather than this one. Retitling around the symptom would make it actionable.