jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Correct placed-structure restore owner split

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 23:57:27 -07:00
commit 8d5fb4f02f
2 changed files with 65 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

25
docs/rehost-queue.md
View file

@ -200,14 +200,27 @@ Working rule:
`0x00422305` computes a live score/category lane before publishing event `0x7`,
`0x004269c9/0x00426a2a` are acquisition commit/clear helpers, and
`0x004282a9/0x004300d6` are bulk owner-transfer writes
- the paired tagged collection loader is bounded away too:
`0x00413440` owns the tagged `0x36b1/0x36b2/0x36b3` triplet load path, dispatches each live
record through vtable slot `+0x44`, and keeps that seam on the already-grounded triplet
payload rather than the missing `[site+0x276]` replay owner
- the paired tagged triplet serializer is bounded away too:
`0x00413440` is the save-side `0x36b1/0x36b2/0x36b3` serializer, dispatches each live record
through vtable slot `+0x44`, and keeps that seam on the already-grounded triplet payload
rather than the missing `[site+0x276]` replay owner
- the ordinary bring-up strip is narrower too:
`0x00444690 -> 0x004133b0` is still the checked ordinary restore-side replay owner above live
placed structures, but it only drains queued local-runtime ids through `0x0040e450` and then
sweeps live rows through `0x0040ee10`; after that, bring-up proceeds into later route-entry,
grid, and tagged refresh owners rather than re-entering the constructor/finalize family
`0x004134d0 / 0x0040f6d0 / 0x0040ef10`
- the broader load-side stream owner is separate too:
`0x00413280` is the actual tagged `0x36b1/0x36b2/0x36b3` stream-load owner, dispatching
per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the
cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct
`[site+0x276]` republisher
- the remaining owner-company question is therefore narrower than “find any replay seam”:
identify which non-transport persisted source family outside the currently bounded direct
allocator/finalize/store families feeds that tuple and which companion restore/finalize calls
are sufficient to repopulate `[site+0x276]` for shellless acquisition
allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
`0x00413280` cached-source bridge, and the checked ordinary replay strip
`0x00444690 -> 0x004133b0 -> 0x0040ee10` feeds the tuple or companion restore calls that are
sufficient to repopulate `[site+0x276]` for shellless acquisition
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`