Rule down post-load region placement branches
This commit is contained in:
parent
0b0420c898
commit
a56d360a3e
4 changed files with 44 additions and 0 deletions
|
|
@ -1565,6 +1565,16 @@ Working rule:
|
|||
`[region+0x27a/+0x27e/+0x282/+0x286]`. So the next non-hook region work should start from the
|
||||
post-load `319` placed-structure replay seam and only then revisit the narrower region-side
|
||||
`320/321` branches if the exact field bridge is still missing.
|
||||
- The `320` branch is narrower than that headline now too: direct worker recovery shows
|
||||
`0x004235c0` staying inside the live region demand-and-placement family by routing through
|
||||
`0x00422900` cached category accumulation, `0x004234e0` projected structure-count scalars,
|
||||
`0x00422be0` placed-count subtraction, and `0x00422ee0` placement attempts over the live
|
||||
placed-structure registry `0x0062b26c`. That keeps it on live setup and maintenance work rather
|
||||
than any restore-time republisher for `[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`.
|
||||
- The `321` branch is narrower in the same way: `0x00437b20` only stages the fast-forward burst,
|
||||
then re-enters the live region collection through `0x00423d30`, and that helper only republishes
|
||||
`[region+0x27a/+0x27e/+0x282/+0x286]` via `0x00422900`. It should stay ruled down as a cached
|
||||
summary refresh instead of a plausible owner for the missing restore-side body lanes.
|
||||
- The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
|
||||
0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
|
||||
region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue