ReviewOS

zig-utils/zig-js

Shapes: reuse exact lookup state across ordinary mutation

#543
Closed chris opened this 9 days ago ·
9 days ago

Parent: #531 Related: #532, #478, #461

Problem

After #532 removed the accessor-reader serialization hotspot, the frozen shared transition-publication row scales through four lanes but still loses aggregate throughput at eight lanes. Current shared attribution shows the partitioned 8-lane invocation publishes 8,008 independent transition misses with zero Shape writer yields, two Object property-lock contentions, and no backing or element contention. A post-change collapsed sample instead places Shape.lookupState first among engine leaves.

The ordinary named-data mutation paths resolve the same immutable Shape/name state more than once while one Object property snapshot is already held:

  • OrdinarySet checks the receiver state, then setOwnUnlocked repeats it;
  • named Delete checks the current slot, then deleteTransition repeats it.

At 8 lanes this adds 16,000 redundant shallow probes to 8,000 exact add/read/delete operations.

Scope

  • Carry a proven Shape.LookupState through the locked OrdinarySet and named Delete mutation helpers.
  • Preserve one public lookup wrapper for callers that do not already hold a proven state.
  • Add opt-in lookup request/comparison attribution if needed to prove the eliminated work without charging production-disabled paths.
  • Keep Shape transition keys collision-independent and exact; do not change the skip-list publication protocol.

No-workaround rules

  • No benchmark recognition, prepublished keys, skipped descriptor/prototype checks, weakened Proxy or accessor semantics, GIL, larger GC threshold, hidden lifecycle exclusion, or reduced work at higher lane counts.
  • Do not modify stacks, queues, jobs, Promise/microtask behavior, or Thread/Worker lifecycle.
  • Do not trade OOM atomicity, delete/re-add ordering, stable slots, same-name convergence, or moving-GC safety for fewer probes.

Acceptance

  • Exact attribution proves one lookup per logically required state observation and identifies every eliminated duplicate.
  • Base, anti-specialization variant, and same-parent contended rows retain frozen checksums and equal timed work.
  • Exact-parent 1/2/4/8 evidence reports wall, CPU/instructions, dispersion, allocation, GC, RSS, and remaining synchronization.
  • OrdinarySet inherited setters/non-writable descriptors, accessors, Proxies, arrays, module namespaces, typed arrays, delete/re-add order, and OOM rollback remain exact.
  • Shape, Object, Array-prototype, and Proxy focused tests plus full units, no-GIL TSan, threadfuzz, moving/parallel GC, and exact-parent test262 pass.
  • Any performance claim waits for clean checked-in raw evidence and report.
9 days ago

The exact-parent diagnostic rejects this optimization, so no code is landing.

I preserved the candidate runner, rebuilt the exact d437b5fc parent with the same ReleaseFast toolchain, and ran seven order-balanced pairs for base, anti-specialization variant, and same-parent contended controls at 1/2/4/8 lanes (1,000 jobs/lane). Every pair retained the frozen checksums.

The partitioned base candidate/parent median wall ratios were 0.9879 / 1.0006 / 0.9998 / 1.0091; the variant ratios were 1.0378 / 0.9876 / 0.9933 / 0.9870. Counter ratios likewise showed no consistent CPU-work reduction. The deliberately contended 8-lane row regressed to 1.0450x parent wall time and won only 2/7 pairs.

The proposed state threading was semantically sound in focused Shape/Object tests, but it added internal API complexity without a causal performance gain. The patch was fully reverted. This negative result also prevents the sampled Shape.lookupState leaf from being mistaken for the remaining >4-lane scaling cause; #531/#478 remain the appropriate parent investigations.

Sign in to comment on this issue.