Correct startup compact effect ownership
This commit is contained in:
parent
6e46c43837
commit
b515fb417b
2 changed files with 14 additions and 10 deletions
|
|
@ -220,11 +220,12 @@ Working rule:
|
|||
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 grouped-opcode family is ruled down too:
|
||||
current direct caller census only reaches `0x00431b20` from scenario runtime-effect service
|
||||
`0x004323a0 -> 0x00432f40` through direct call `0x00432317`, so `0x0061039c` currently reads
|
||||
as a live runtime-effect application lane rather than the missing persisted restore owner for
|
||||
`[site+0x276]`
|
||||
- the grouped-opcode family is narrower rather than fully ruled down:
|
||||
`0x00431b20` is still only reached through scenario runtime-effect service
|
||||
`0x004323a0 -> 0x00432f40` via direct call `0x00432317`, but that service loop is itself
|
||||
called from world bring-up at `0x00444d92` with trigger kind `8` under shell-profile latch
|
||||
`[0x006cec7c+0x97]`; so `0x0061039c` currently reads as a startup-time live runtime-effect
|
||||
application lane rather than an ordinary tagged restore owner
|
||||
- the `[site+0x27a]` companion lane is grounded now too:
|
||||
it is a live signed scalar accumulator rather than a second owner-identity seam, with zero-init
|
||||
at `0x0042125d` and `0x0040f793`, accumulation at `0x0040dfec` and `0x00426ad8`, direct set on
|
||||
|
|
@ -233,9 +234,9 @@ Working rule:
|
|||
identify which non-transport persisted source family outside the currently bounded direct
|
||||
allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
|
||||
`0x00413280` cached-source bridge, the checked ordinary replay strip
|
||||
`0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the live runtime-effect dispatcher
|
||||
`0x00431b20` feeds the tuple or companion restore calls that are sufficient to repopulate
|
||||
`[site+0x276]` for shellless acquisition
|
||||
`0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the startup-time runtime-effect dispatcher lane
|
||||
`0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20` feed 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]`
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue