Skip to content

Make memory accounting lock-free - #12

Merged
alexy merged 1 commit into
mainfrom
work/lock-free-memory
Sep 20, 2026
Merged

alexy merged 1 commit into
mainfrom
work/lock-free-memory

Conversation

@alexy

@alexy alexy commented Sep 20, 2026

Copy link
Copy Markdown
Member

Implements docs/lock-free.md as designed; that file now records the outcome.

ExecutionContext holds accounted bytes and their high-water mark as atomics and admits a memory charge through the same compare-exchange loop as a work charge, so a byte limit stays exact under concurrent charges. Releases are one fetch_sub. Only the cancellation wakers stay behind the mutex.

Why: the reference Cypher executor charges the logical bytes of every copied value, so a streaming query charges memory once or more per element. The lock was about 11% of the profile of the full-path reduce query.

Behaviour that changes

  1. usage() reads its three figures in sequence, not as one snapshot. It reports max(peak, live), so peak_bytes >= live_bytes for every reader; read after execution for exact totals.
  2. The peak can trail a charge for an instant; it never misses a completed charge.
  3. A poisoned lock no longer fails a memory charge. Only waker registration can report poisoning.

Tests

tests/contracts/memory.rs: sixteen threads racing for a limit that fits exactly fifty chunks admit exactly fifty, over fifty rounds; cross-thread drops return live_bytes to zero; the peak is a true maximum, unmoved by refusals, never observed below live by a racing reader; overflow is a budget failure. Not model-checked with loom. 1,297 tests pass across grust-core, grust-cypher, grust-memory, grust-turso, grust-algorithms, grust-algorithm-procedures and grust-datafusion.

Measured (one laptop, release, whole-process wall time, best of seven)

query nodes mutex lock-free
reduce fold 1,024 301 ms 267 ms
reduce fold 4,096 4,389 ms 3,815 ms
UNWIND aggregate 4,096 862 ms 859 ms
direct kernel 4,096 108 ms 107 ms

The lock-free figure was measured before and after the mutex figure and reproduced. Paths that charge memory rarely do not move, so the regression the plan guarded against did not appear here. The paired benchmark-harness run has not happened and these figures are not a substitute for it.

🤖 Generated with Claude Code

@alexy
alexy force-pushed the work/lock-free-memory branch from 31d4a7b to 5db3b08 Compare September 20, 2026 09:21
docs/lock-free.md, L1 to L4. live_bytes and peak_bytes are atomics admitted by
the same compare-exchange as work units; only cancellation wakers keep the
mutex.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@alexy
alexy force-pushed the work/lock-free-memory branch from 5db3b08 to 8fca3ee Compare September 20, 2026 10:11
@alexy
alexy merged commit 0995224 into main Sep 20, 2026
1 check passed
alexy added a commit that referenced this pull request Sep 20, 2026
Documentation only.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
alexy added a commit that referenced this pull request Sep 20, 2026
The recipe's check that no code changed on main after #12 now fails: four
commits touch crates/ since 0995224. The pin keeps that commit and loses the
label "main". Adds an input on the fourth-pin question and offers to build the
historical pins off quegee's critical path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
alexy added a commit that referenced this pull request Sep 20, 2026
Confirms the four pins form a linear ancestor chain, that cee2693 is still the
newest code-changing commit on main, and that the harness and Turso pins match.
Notes that main against #12 is a difference rather than a delta, since five
commits touch crates/ between them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
alexy added a commit that referenced this pull request Sep 20, 2026
…, sweep is sequential-only

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sak2FQcdgs5pkL2ruKrSUZ
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