pub fn arc_string_constant(s: String) -> u64Expand description
Compile-time helper: produce a §2.7.5 Arc::into_raw-shape carrier
pointer for a MirConstant::Str / MirConstant::StringId site,
content-deduplicated through the program-wide [intern_pool].
The constant is embedded as an iconst I64 in the JIT-emitted code, so
the bits are static across every runtime occurrence of the site. The
intern pool keeps one Arc<String> per distinct content alive for the
program’s lifetime (process-wide static OnceLock<Mutex<HashMap<…>>>);
the iconst payload is Arc::as_ptr(&pool_arc) as u64 — the same raw
pointer shape as the prior Arc::into_raw-with-refcount-boost
discipline, so consumers (jit_arc_string_retain /
jit_arc_string_release, KindedSlot::Drop for NativeKind::String,
VM-side Arc::from_raw(bits as *const String)) need NO change.
Refcount discipline (preserved per call). Each call bumps the
strong count by 1 to preserve the pre-fix “active share” safety
against unpaired releases (e.g. a JIT-emitted release without a
matching retain would otherwise underflow when the pool’s share
is the only one). Pre-fix this was Arc::increment_strong_count on
every freshly-allocated Arc (boost from 1 → 2); post-fix it is the
same increment on the pool-owned Arc. Dedup at the allocation layer
does NOT change this per-call refcount discipline.
Heap-memory savings (the §5.1 measurement target). The dedup
property: repeat occurrences of the same constant (e.g. prog3’s
print("hello") × 5) share one underlying Arc<String>
allocation — one String heap buffer + one Arc control block,
strong_count = 1 (pool) + N (per-call boosts). Pre-fix: 5x
Arc::new("hello") = 5 separate String heap buffers + 5 Arc
control blocks. Post-fix: 1 of each, regardless of call count.
STRING_CONSTANT_ALLOCS counts actual Arc::new invocations
(= distinct-content allocations = leaked-allocation count per §F.1).