Reduce PerLevelDataLoaderDispatchStrategy bookkeeping: pack per-level counters into one AtomicLong - #4502

What

PerLevelDataLoaderDispatchStrategy.CallStack keeps two counters per level (happenedExecuteObjectCalls, happenedCompletionFinishedCount). Today they live in an immutable StateForLevel behind ConcurrentHashMap<Integer, AtomicReference<StateForLevel>>, so every executeObject and every object completion:

1. does a computeIfAbsent lookup on the map,
2. allocates a new StateForLevel,
3. retries a compare-and-set until it wins, which under concurrent completions on the same level means repeated allocation and retries.

The readiness check (isLevelReady) also reads the two counters with separate get() calls.

This PR stores each level's counters in one AtomicLong: the completion count in the high 32 bits and the execute-object calls in the low 32 bits. The levels sit in an array indexed by level, which grows on demand; query depth bounds its size.

• Increments: a single getAndIncrement / getAndAdd, with no allocation and no retry loop.
• Readiness: allExecuteObjectCallsCompleted(level) reads both counters from one snapshot.
• Hot path: a volatile array read. Only creating a new level, or growing the array, is synchronized.
• Compatibility: get(level) and tryUpdateLevel(...) keep their signatures, so the existing tests and the subscription/defer paths that use them work unchanged. No public API changes.

Benchmark

PerLevelDispatchOverheadPerformance (new) isolates the strategy's cost. It runs the same wide query (items(250) { a b c d e child { x y grand(5) { v w } } }) with the same data fetchers, none of which use a DataLoader, in two modes:

• none: no DataLoaderRegistry, so the engine uses the no-op dispatch strategy;
• perLevel: a registry holding one unused loader, which switches the engine to PerLevelDataLoaderDispatchStrategy.

The difference between the two modes is everything the strategy costs. With async = true, a scalar field on every item completes on a 4-thread pool, so completions for the same level race on the per-level state. That matches servers whose fetchers resume on worker threads.

Results with 5 forks, in µs/op (./gradlew jmh -PjmhInclude=PerLevelDispatchOverheadPerformance, JDK 25, Apple M-series):

With async completion the strategy's overhead disappears; with synchronous fetchers there is no measurable change. Allocation per op is unchanged within noise.

PerLevelDispatchPerformance (also new) is the same query shape with a real DataLoader-backed child field, for an end-to-end view. Its timings were within noise before and after, because the DataLoader dispatch itself dominates there.

I'd welcome a run on your isolated performance environment, since these numbers come from a laptop.

Tests

• New Spock cases in PerLevelDataLoaderDispatchStrategyTest:
  • level counters beyond the initial array capacity (level 40), the single-snapshot readiness check, and clear();
  • 8 threads × 10k increments across 20 levels with no lost updates.
• Full suite: ./gradlew test passed locally (5,792 tests).

🤖 Generated with Claude Code