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,752backing allocations /295,563,907bytes,1,276,304GC-cell allocations,47collections - range parts: checksum
789386393,3,651,166backing allocations /480,780,437bytes,2,025,117GC-cell allocations,73collections
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
typeand rangesourcethrough the engine's immutable static string-cell path. - Keep formatted
valuestrings 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.