Hi V8 folks,
I found a snapshot deserialization failure involving deferred objects and
off-heap TypedArray backing stores, and uploaded a CL with a proposed fix:
The failing case is roughly:
- Create a Uint8Array with an off-heap backing store.
- Store it behind an object chain so it can be serialized through the
deferred-object path.
- Create a custom snapshot blob.
- Restore the snapshot and read bytes from the restored TypedArray.
Before the fix, the test fails during deferred-object deserialization.
The failure happens because JSArrayBuffer/JSTypedArray serialization can
emit off-heap backing-store records before the object body.
However,
deferred-object deserialization expects only NewObject or Synchronize
bytecodes at the top level of the deferred stream.
The proposed fix is to avoid deferring JSArrayBuffer and JSTypedArray.
This keeps the deferred-object stream invariant intact instead of making
the deserializer accept backing-store records in that path.
I considered fixing this on the deserializer side, but that seemed riskier:
it would make the deferred-object stream accept additional top-level record
types, weakening the current invariant and potentially hiding other ordering
issues. Preventing these objects from being deferred seems narrower and more
consistent with the existing deferred deserialization assumptions.
Does this direction look right, or would V8 prefer handling this in the
deserializer instead?
Thanks!
Zekai