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:
https://chromium-review.googlesource.com/c/v8/v8/+/7930626 The failing case is roughly: 1. Create a Uint8Array with an off-heap backing store. 2. Store it behind an object chain so it can be serialized through the deferred-object path. 3. Create a custom snapshot blob. 4. 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 -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/c4ecf431-ffc1-4d52-b1b0-ab75a52f46a6n%40googlegroups.com.
