JosephFerano/flan
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Keep the registry simple; revisit only on evidence

Browse Source
This commit is contained in:
Joseph Ferano 2026-09-13 08:59:27 +07:00
parent fc6b0f5aba
commit 83369196a9
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
NEXT.md
View File

@ -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.