ReviewOS

zig-utils/zig-js

Perf: initialize object cells without a full default-template copy

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

Parent: #62 Negative precursor: #68

Problem

The optimized ordinary-object path allocates a 624-byte Object payload and then copies a full static Object{} template into every fresh or reused cell. The current object_churn profile attributes 24 top-of-stack samples to platform memmove, with the call tree rooted at VM new_object, while #68 showed that changing only slab spacing regresses performance. The payload initialization itself is the next measured allocation cost.

Scope

  • add one canonical Object initializer that zero-fills private storage and explicitly restores every nonzero or representation-sensitive default;
  • use it from GC and arena object allocation paths without changing Object layout;
  • keep inline slots self-referential and valid after initialization;
  • preserve atomics, mutexes, optional values/allocators, empty slices/lists/maps, extensibility, and undefined-valued internal slots;
  • add focused tests that exercise ordinary properties plus representative exotic flags/storage after initialization;
  • inspect optimized code to prove the 624-byte template memcpy is gone;
  • retain only if clean pinned object_churn A/B improves with exact checksum equality.

Acceptance criteria

  • The optimized newObject allocation path no longer calls memcpy/memmove for Object{}.
  • Fresh and reused GC cells receive identical observable defaults.
  • Inline slots, elements, weak/finalization lists, maps, locks, atomics, slices, optionals, and Value defaults are valid.
  • Ordinary, array, proxy, regex, weak-ref/finalization, typed-buffer, and Temporal tests remain clean.
  • Focused GC/no-GIL initialization coverage passes.
  • Clean pinned object_churn A/B shows a repeatable improvement at checksum 1030552128.
  • Commit references this issue and evidence is added to #62.
9 days ago

Rejected after optimized-code inspection and clean pinned measurement; the experiment has been fully removed and no commit was made.

The candidate did satisfy the mechanical goal: ARM64 newObject changed from a 624-byte memcpy/memmove of Object{} to bzero plus explicit default stores, and its focused initialization test passed 2/2. Performance was worse:

  • pinned main baseline median: 614.898 ms
  • zero-fill candidate median: 628.118 ms
  • regression: 2.15%
  • 12 order-balanced fresh warmed processes per binary, 100 object_churn jobs each
  • exact checksum 1030552128 in every run

The constant template is hot and the platform copy beats clearing plus sparse fixups. #62 should instead target work that can be removed entirely, especially managed barrier ownership classification and bytecode dispatch.

Sign in to comment on this issue.