ReviewOS

zig-utils/zig-js

Intl.DateTimeFormat: intern structural part metadata

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

Parent: #475 Depends on: #572, #573, #574

Problem

Intl.DateTimeFormat.prototype.formatToParts and formatRangeToParts currently allocate a fresh StringCell and backing copy for every type and source value. Those metadata values are selected exclusively from a closed set of engine-owned immutable literals; only each formatted value needs result-owned storage.

Exact-parent (9f6a8e5e) attribution at 100 jobs records:

  • parts: checksum 723681062, 2,236,752 backing allocations / 295,563,907 bytes, 1,276,304 GC-cell allocations, 47 collections
  • range parts: checksum 789386393, 3,651,166 backing allocations / 480,780,437 bytes, 2,025,117 GC-cell allocations, 73 collections

The representative rows are dominated by creating the specified JS part arrays and objects, but copying immutable metadata is avoidable native overhead inside that required structure.

Scope

  • Represent every DateTimeFormat part type and range source through the engine's immutable static string-cell path.
  • Keep formatted value strings independently owned; never borrow scratch buffers or dynamic formatter output.
  • Make the metadata set explicit and exhaustive so a future dynamic part type cannot silently acquire the wrong lifetime.
  • Preserve exact text, part boundaries, range source attribution, property ordering, and ordinary mutable result objects.

Acceptance

  • Exact-parent and system-JSC checksums remain identical for parts and range-parts controls.
  • Attribution demonstrates fewer backing allocations/bytes without increasing GC-cell allocations or collections.
  • DateTimeFormat and Temporal test262 subtrees have no regressions.
  • Focused normal, TSan, moving-GC, bounded-heap, OOM, and no-GIL coverage pass.
  • Full sharded units pass.

Exclusions

No Promise, microtask, Worker, queue, or job-lifecycle changes; those remain separately owned.

9 days ago

Landed on main in perf(intl): intern DateTimeFormat part metadata (#575).

DateTimeFormat part types and range sources now use closed native enums backed by process-lifetime immutable string cells. Dynamic formatted values remain independently owned, and the returned arrays/part objects remain ordinary mutable JavaScript objects. The typed representation also turns structural range type checks into enum comparisons.

Exact-parent (9f6a8e5e) evidence at 100 jobs:

  • formatToParts: backing allocations 2,236,752 -> 2,153,550 (-3.72%), GC cells 1,276,304 -> 1,193,104 (-6.52%), collections 47 -> 45, cumulative backing bytes -556,380
  • range parts: backing allocations 3,651,166 -> 3,484,768 (-4.56%), GC cells 2,025,117 -> 1,858,717 (-8.22%), collections 73 -> 70, cumulative backing bytes -771,410
  • property-lock counts are unchanged
  • checksums remain exact against the parent and system JSC: parts 723681062, range parts 789386393
  • opposite-order 11-sample medians: parts 0.976x / 0.994x; range parts 0.986x / 0.991x parent

Verification:

  • DateTimeFormat 244/244
  • Intl402 Temporal 2,029/2,029
  • built-ins Temporal 4,603/4,603
  • affected flips 0
  • focused normal and TSan 7/7, including bounded heap, OOM, moving GC, and no-GIL
  • full units 1,658 pass / 1 skip / 0 fail / 0 leak
  • format and diff checks clean

Sign in to comment on this issue.