Skip to content

Hand the generated loop's own Maps on at the run's last use - #1437

Merged
jasisz merged 2 commits into
mainfrom
loop-hand-on-small-maps
Sep 25, 2026
Merged

jasisz merged 2 commits into
mainfrom
loop-hand-on-small-maps

Conversation

@jasisz

@jasisz jasisz commented Sep 25, 2026

Copy link
Copy Markdown
Owner

__bump (run.versions) and __park (moved.slots) copied their Map on every answer on the VM. Each one read the run whole inside the same record update that sets the Map: __versionOf(run, owner) in __bump, and moved.now / __versionOf(moved, owner) in __park. That meant the #1429 field take could never apply.

What changes (generated Aver only)

  • __bump and __park. Both bind the version (and in __park the clock) first, then update the run at its last use. The Map field is read once, inside the update that replaces it.
  • __take<Module>. It now returns (run.<field>, __Run.update(run, <field> = Option.None)): the state is read first and the run is updated at its last use. The update then moves the run's other fields instead of leaving the dead run holding slots and versions. The tuple order flips, and __serve<P> matches (__held, __rest).
  • __seatFamily<P>. Same class of problem, found by the warning: it passed kept.retired<P> and Map.keys(kept.retired<P>) to one call. It now lists the keys first.

perf-shared-update on the generated functions

The warning skips __ functions, so I checked with that filter lifted locally (the change is not committed). I ran aver check on run_all_slice, run_owned_answer_state, run_schedule_cases and run_families:

  • main: reports __bump, __park and __seatFamilyMember.
  • this branch: reports nothing in any generated function.

Measurements

Map writes the runtime refused because something else held the Map, from aver run --profile, release build without LTO:

main this PR alone #1436 alone #1436 + this PR
run_owned_answer_state 802 802 403 4
same, 2000 requests / 100k-entry state 8002 8002 4003 4

On its own this PR does not change the VM numbers. The run reaches __serve<P><Kind> through the __take tuple, and on main that tuple still holds the run (#1436 fixes that). With #1436 in, the per-answer copies of the loop's own Maps go away. These Maps are small, so wall time does not move (0.125 s vs 0.126 s at 2000 requests).

Tests

  • run_all_spec: the dump test now pins the three new shapes. rust_work_spec pins let (__held, __rest) = __takeOwner(run);, and the Rust side still hands the state over by value.
  • Passing locally: run_all_spec, rust_work_spec, yield_verify_spec (including the Lean check of the coordinator laws: __park law anErrKeepsTheInstance stays universal), and wasm_work_spec --features wasm.
  • python3 tools/regenerate_self_host.py --check: the self-host does not change. cargo fmt is clean.

jasisz and others added 2 commits September 25, 2026 09:18
__bump read the run whole (__versionOf(run, owner)) inside the update
that sets run.versions, and __park did the same with moved.now and
__versionOf(moved, owner) inside the update that sets moved.slots, so
on the VM neither record update could take its Map field out and every
answer copied both Maps. perf-shared-update reports both when it is
allowed to look at generated functions.

Both now read everything else first and update the run at its last use.
__take<Module> reads the state before it updates the run, so the update
moves the run's other fields instead of leaving the old run holding
them, and __seatFamily<P> lists the retired keys before it hands the
retired Map to __unretire<P>. With the generated-function filter lifted,
perf-shared-update reports nothing in the loop fixtures.

On the VM the gain shows together with the consumed-tuple release
(#1436), since the run reaches __serve<P><Kind> through the __take
tuple: on run_owned_answer_state the writes refused because something
else held the Map go from 403 to 4, and on its 2000-request version from
4003 to 4. The Maps are small, so wall time does not move.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@jasisz
jasisz merged commit 23f06bb into main Sep 25, 2026
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant