getReplicationSharedStatus allocates per call on the blob-retrieval request path #928

getReplicationSharedStatus() allocates on every call, and it is called on the blob-retrieval request path.

Mechanism (harper-pro main @ 02f3eb9)

replication/knownNodes.ts:102-116 builds, per call:

• a new ArrayBuffer(REPLICATION_SHARED_STATUS_SLOTS * 8) = 256 bytes, evaluated eagerly whether or not the native side uses it,
• a fresh external-ArrayBuffer wrapper and its native finalizer struct,
• a new Float64Array view.

Every other getUserSharedBuffer caller in the codebase caches the resolved view once. This one does not.

replication/replicator.ts:477 (Loader.load) calls it once per residency candidate, inside the cache-miss retrieval loop — so the per-call cost multiplies by the residency set size on exactly the path that is already a miss.

Status

Performance only; no correctness impact. PR #845 explicitly considered an in-function retain cache and rejected it, so this is knowingly left rather than overlooked — filing it so the decision is tracked rather than rediscovered.

Re-verified 2026-09-22: the only commit touching either file since 2026-09-15 is 2294689 ("Cluster record locks (#822)", 2026-09-18), whose knownNodes.ts diff is comment-only. Function body unchanged.

— Claude Opus 5.5