StructuredClone serialize / deserialize

[annevk]

See tc39/proposal-ecmascript-sharedmem#39 (comment). The way we define structured cloning right now is not correct.

What we need is some kind of "Agent Message Record" which holds a serialization of an object graph (probably also defined as a record). Those records are then passed around between agents/realms (using postMessage()) and can sit still for a while in a MessagePort' queue until its started for a particular agent/realm. (Although maybe it needs to be bigger if we actually want to carefully define how those tasks get transferred between event loops too. Or we pretend tasks are magic.)

tc39/proposal-ecmascript-sharedmem#39 (comment) has thoughts on how to approach this.

@lars-t-hansen, let me know when this becomes higher priority.

@jungkees @jakearchibald this is probably also important for service workers for when we'll start specifying the messages going to and from clients in more detail.

[domenic]

We discussed this a bit more in #jslang, from a slightly different perspective. If we want to be able to structured clone promises and streams between workers and the main thread, we need some distinction which doesn't allow those to be serialized to IndexedDB, since that doesn't work or make sense. My proposed framework is then:

• Objects can have three possible operations:
  • Serialize(object): object -> lists-and-records
  • Deserialize(serialization, targetRealm): lists-and-records -> new object created in targetRealm
  • Entangle(object, targetRealm): object -> new object created in targetRealm which is "entangled" with the original object
• An object that has Serialize must have Deserialize; an object that has Entangle must not have Serialize or Deserialize.
• Moving stuff between realms is done via structured cloning, which does either Serialize + Deserialize, or Entangle, depending on the object being cloned.
• IDB and other storage-type things no longer use structured clone. Instead, they directly use Serialize and Deserialize.
  • Serialize does not work on things that must be transfered, like MessagePorts. This is already how IDB works.

An example of Entangle for promises is, creating a new promise p in targetRealm, then doing basically object.then(resolveP, rejectP) where resolveP and rejectP resolve/reject p with a structured clone of their argument.

An example of Entangle for streams is basically doing what we are doing in fetch/service workers today to pass things over the service worker boundary to the main thread. If this work is done carefully we could probably replace all that spec text.

[annevk]

Two complications: 1) Serialize does not mean persist to IDB, e.g., SharedArrayBuffer. 2) Serialize and Deserialize happen in different tasks and can each fail. We currently do not handle failure for the latter.

[domenic]

Can you expand on

Serialize does not mean persist to IDB, e.g., SharedArrayBuffer

? @inexorabletash was talking about something similar but my understanding is that this hasn't been decided exactly how SAB and IDB should interact.

My thought for something like SharedArrayBuffer or Blob is that the result of serialization would be a record like { [[Type]]: "SharedArrayBuffer", [[BackingData]]: the [[ArrayBufferData]] of the source } or { [[Type]]: "Blob", [[BackingData]]: a pointer to the data }. The actual process of serializing these to disk (i.e. translating them into bytes) would be implementation-specific.

[annevk]

@lars-t-hansen told me that was desired.

[domenic]

Right. But why does that mena "Serialize does not mean persist to IDB"?

[annevk]

It means "storage/persist" and Serialize are distinct. Supporting the latter does not imply the former.

[domenic]

OK. I don't understand your point then or how it relates to SAB. SharedArray would support Serialize and would be storable/persistable.

[lars-t-hansen]

Briefly, for me the question is, which operation does postMessage use? It can't be Serialize if that makes a copy of shared memory as it would have to for IDB.

[domenic]

Serialize does not make a copy of shared memory, neither for postMessage nor for IDB. It just serializes to the record of the form { [[Type]]: "SharedArrayBuffer", [[BackingData]]: the [[ArrayBufferData]] of the source }. When this is Deserialized by postMessage, it just creates a new SAB with the pointer to [[BackingData]]. When IDB performs its implementation-specific records-to-bytes translation, it makes a copy of the data.

[annevk]

@domenic all I'm saying is that we wouldn't allow SharedArrayBuffer to be stored. So the theoretical Store/Persist abstract operation that takes the result of the Serialize operation would fail on SharedArrayBuffer records. (I suspect this is because the underlying data is much more mutable than with other kind of objects. Only File objects have somewhat similar characteristics, but those would require the user to go in and modify the underlying resource.)

[annevk]

And IDB doesn't make a copy of the data necessarily. For File objects it just stores a pointer, as far as I know. If it made a copy of the data it would do more than structured cloning offers and I don't think it does that (which is the main reason why we don't want SharedArrayBuffer there I think, presumably this also applies to the Notifications API).

[domenic]

Why wouldn't we allow SAB to be stored??

[annevk]

What would storing it mean? Would it mean copying the underlying data? It's not really a primitive that's defined nor necessarily desired for v1.

[domenic]

Yes, copying the underlying data, exactly the same as for ABs. It is indeed not defined how that happens, since it's implementation specific.

[lars-t-hansen]

Clearly the SAB's data can be stored (though of course there's no guarantee that the data are stable while the storing is going on :) The SAB itself can't be stored in the same way that a closure can't usefully be stored, though.

I probably don't care very much how this is resolved, so long as we're clear on what the misc operations do. I think it's Weird that IDB has an implementation-specific mechanism for persisting data that could accept a type in one embedding and not in another (IIUC), but I don't think it matters for my purposes.

[domenic]

To be clear what I mean by implementation-specific: I mean that the actual byte pattern on disk/in memory used is implementation specific. The "records-and-lists" structure is meant to be an implementation-agnostic (and, more importantly, realm-agnostic) representation of the data, but how that gets translated into a byte pattern is necessarily implementation specific. This implementation-specific serialization is not just for IDB; it's also used in IPC for postMessage and friends.

[annevk]

It's not the same as regular AB since the underlying data isn't shared for regular AB.

[domenic]

That doesn't impact anything relevant here.

[annevk]

It does, because the SAB you get back may or may not point to a different buffer depending on how storage is defined.

[inexorabletash]

And IDB doesn't make a copy of the data necessarily. For File objects it just stores a pointer, as far as I know.

Tangent, but IDB implementations do copy the File contents - basically the same work as for Blobs. Even outside IDB the behavior of a File when the file on disk is modified is inconsistent between browsers. (At some point the spec effectively required doing a full data copy on file selection, but no browser does that.)

[annevk]

We should get that defined.

[inexorabletash]

w3c/FileAPI#47 and possibly others.