Do we need Shared Data Block?

[annevk]

The way StructuredClone works is by simply assigning a Data Block to a new output ArrayBuffer across Agents and then detaching the input ArrayBuffer. So in effect they are already shared across Agents, we just make sure to detach them.

I think it would be better to just make this sharedness a clarification around what actually happens to a Data Block than introducing a new type.

[lars-t-hansen]

At the moment, a Shared Data Block has some special semantics attached to it in the shared memory spec: a Shared Data Block has an address-free identifier G that identifies it within the cluster, for one thing. If there's no such thing as a Shared Data Block I'll have to start talking about "a Data Block that is shared", which is scarcely an improvement; it also introduces uncertainty around existing mentions of Data Block in ES6 - for every mention, it needs to be clarified that none of them allow for the block to be shared. (That may not be a big deal.)

What you are describing is an optimization, IMO, and not an essential part of StructuredClone (I'd be most interested to know if I'm wrong on that). An implementation that copies a Data Block and frees the old one would - I think - be observationally equivalent to one that transfers the memory as you describe. That would never be true for a Shared Data Block.

[annevk]

So actually, StructuredClone does clone the Data Block. StructuredCloneWithTransfer does the pointer swap from input to output and then detaches. But yes, StructuredCloneWithTransfer could also clone and then detach. And implementations could optimize that.

Not sure if that is a better definition, since we expect implementations to make that optimization as otherwise the performance characteristics would not be up to par.

[lars-t-hansen]

I'd be nervous about requiring StructuredCloneWithTransfer to transfer the memory. On some operating systems or CPUs it may not be possible to transfer memory between processes without explicitly setting that up when the memory is created, and that setup might have a fair amount of overhead so you don't normally want to do it. Yet we'd want to run multiprocess browsers (or other embeddings) on such systems, and sometimes it might be necessary for a "transfer" to happen between processes. Suppose we only run one ServiceWorker instance for all tabs for a domain (waving my hands here about how ServiceWorkers actually work). If tabs run in separate processes a transfer of memory from some tabs to the ServiceWorker might not be able to avoid the copy.

An implementation note about the optimization seems more reasonable than a requirement, IMO.

[lars-t-hansen]

BTW, this is why there's some hedging in the spec(s) about how shared memory can be shared, this is strictly speaking an HTML issue whether we can refuse to clone something depending on the destination (which may not be known on a MessageChannel, actually) and I'm happy not to have to worry about that except that it probably needs to be necessary for the implementation to say "no" to some transfers and there needs to be some kind of mechanism in the HTML spec for that. That's Issue #39, which you probably should look at.

NOTE here
NOTE 3 here

[lars-t-hansen]

I'm going to close this, because I think the separate Shared Data Block concept does pay for itself in the spec, at least for now.