Home » Javascript » JavaScript Transferable Objects: Why doesn't the engine preserve the original instance?

JavaScript Transferable Objects: Why doesn't the engine preserve the original instance?

Posted by: admin November 1, 2017 Leave a comment

Questions:

I’m reading this article on web workers and I came across this section on Transferable Objects:

With Transferable Objects, data is transferred from one context to another. It is zero-copy, which vastly improves the performance of sending data to a Worker. Think of it as pass-by-reference if you’re from the C/C++ world. However, unlike pass-by-reference, the ‘version’ from the calling context is no longer available once transferred to the new context.

Why? Based on my understanding of Abstract Stack Machines, it seems perfectly reasonable that original pointer can be left in tact. Admittedly, since the data is now referenced from another context, it would be a tricky task to continue working with it, but not totally unreasonable. Why is the original object cleared?

I’d also like to learn how this whole process takes place under the hood, if anyone has some valuable insight there.

Answers:

One possible reason to transfer an object would be to reduce the amount of memory used for storing multiple copies of the same object.

2.7.2 Transferable objects

Transferable objects support being transferred across event loops.
Transferring is effectively recreating the object while sharing a
reference to the underlying data and then detaching the object being
transferred. This is useful to transfer ownership of expensive
resources. Not all objects are transferable objects and not all
aspects of objects that are transferable objects are necessarily
preserved when transferred.

Note:
Transferring is an irreversible and non-idempotent operation. Once an
object has been transferred, it cannot be transferred, or indeed used,
again.

Platform objects can be transferable objects if they implement only interfaces decorated with the [Transferable] IDL extended attribute. Such interfaces must also define the following algorithms:

transfer steps, taking a platform object value and a Record dataHolder

A set of steps that transfers the data in value into
fields of dataHolder. The resulting data held in dataHolder must be independent of any JavaScript Realm.

These steps may throw an exception if transferral is not possible.

transfer-receiving steps, taking a Record dataHolder and a platform object value

A set of steps that receives the data in dataHolder, using it to set up value as appropriate. value will be a newly-created instance of the platform object type in question, with none of its internal data set up; setting that up is the job of these steps.

These steps may throw an exception if it is not possible to receive the transfer.

It is up to the definition of individual platform objects to determine what data is transferred by these steps. Typically the steps are very symmetric.

See also 2.9.2. Transferable objects