ReviewOS

zig-utils/zig-js

Strings: remove serial FNV from managed-cell construction

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

Parents: #473, #479 Related: #461, #493

Evidence

After #597/#598 removed the prior root-owner and root-lock hotspots, a fresh five-second current-main (6c246bb6) production cold profile of representative_temporal_availability records 1,437 top-of-stack samples in gc.finishManagedString, overwhelmingly mapped to strcell.contentHash. The next active engine leaf is Shape.lookupState at 318 samples. The main thread’s independent-lane join is lifecycle/scheduler work owned separately and is explicitly out of scope here.

Every managed runtime string currently runs a byte-serial FNV-1a recurrence while also deriving ASCII/Latin-1 classification. The cached hash is an internal fast reject: equality remains exact by bytes, and representation flags are deterministic from content.

Scope

  • Replace the serial cached-content hash with a repository-owned, deterministic high-throughput hash already available in Zig stdlib.
  • Preserve the top-bit ASCII/Latin-1 representation flags and exact byte equality on every collision.
  • Make classification a compiler-vectorizable pass without changing canonical WTF-8 or flat-string representation.
  • Keep compile-time literal cells and runtime managed/arena/external string constructors hash-compatible.
  • Measure the isolated constructor/hash path and the exact-parent production cold lifecycle.

Security and correctness constraints

  • Hashes may reject unequal strings but never establish equality; exact bytes remain authoritative.
  • Do not expose the internal hash as a language-observable value or ABI promise.
  • No benchmark recognition, cached benchmark output, skipped canonicalization, weakened Unicode validation, or unbounded interning.
  • Any hash-table use over attacker-controlled strings must retain exact collision resolution and its existing synchronization/lifetime rules.
  • Do not touch stacks, queues, jobs, Promise, microtasks, Worker lifecycle, or scheduler implementation.

Acceptance

  • Exact-parent cold samples improve with identical checksum, allocation, GC-cell, execution-tier, shape, heap, and synchronization inventories.
  • A fixed-duration collapsed profile materially reduces the contentHash leaf.
  • ASCII, Latin-1, BMP, astral, and lone-surrogate hash/classification tests cover static and runtime cells plus forced hash-collision equality.
  • String/RegExp/JSON/Temporal-adjacent test262, focused normal/TSan/OOM/GC tests, and full units pass without leaks.
9 days ago

Landed on main in 043f9788 (perf(strings): vectorize cached content hashing (#599)).

Managed and arena StringCells now use deterministic XXH3 for the 62-bit cached fast-reject hash plus an explicit 16-byte ASCII/Latin-1 classification reduction with an overflow-safe scalar tail. Compile-time literals and runtime cells remain hash/representation compatible. Hash equality never establishes JavaScript equality: exact bytes remain authoritative, covered by a forced-collision test. No string representation, canonical WTF-8, interning lifetime, or jobs/lifecycle surface changed.

Verified against exact parent 6c246bb6:

  • 21 alternating production cold pairs: 12.938 ms → 10.423 ms (-19.44%), checksum 1 throughout
  • fixed five-second cached hash/classification leaves: 1,437 → 859 (-40.2%)
  • allocation, GC-cell, execution, admission, synchronization, shape, heap, pause, native-code, and cell-slab inventories exact
  • test262: 0 flips across String 1,223/1,223, RegExp 1,879/1,879, JSON 165/165, Temporal 4,603/4,603
  • full units: 1,715 passed, 1 skipped, 0 failed, 0 leaked
  • focused normal + TSan string, heap-pressure, moving-GC, Intl relocation, and protected C-API StringCell witnesses pass.

Sign in to comment on this issue.