From 83369196a936b84a719d3e26094bfab2a7f6302b Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sun, 13 Sep 2026 08:59:27 +0700 Subject: [PATCH] Keep the registry simple; revisit only on evidence --- NEXT.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/NEXT.md b/NEXT.md index 49effe8..963e2b1 100644 --- a/NEXT.md +++ b/NEXT.md @@ -47,11 +47,11 @@ Costs nothing in a release build. **What it does not cover, and does not need to:** stack locals and globals, which the shadow stack and the static type table already answer by name. -**The cost to watch, and it is the design question.** An arena allocation is a bump pointer — close to free — and a -registry insert per allocation could easily cost more than the allocation itself, in a loop that runs every frame. -Mitigations to weigh: record per *region* rather than per allocation; record ranges rather than addresses; or make the -registry opt-in per allocator so a frame arena can decline it. Decide this before building, because it determines -whether the feature is usable in the loop it is most wanted in. +**On cost — settled by the author: keep it simple.** One registry insert per allocation, always on in a dev build, +no opt-out. An arena allocation is a bump pointer and an insert may well cost more than the allocation itself in a +per-frame loop, but a dev build already carries indirection cells and a shadow stack, and the author's instruction is +to build the straightforward thing and revisit only if a real program shows a problem. Do **not** build per-region +recording, range recording, or a per-allocator opt-out on speculation. **Note on classes:** `defclass` instances will carry shape metadata by design, so they get identification for free and do not need the registry. This is for plain structs, `Vec`, `Map` and pool storage.