Re: [w3ctag/design-reviews] JavaScript WeakRefs (#321)

> * The statement near the end that "To avoid leaking, cycles across isolated heaps must be explicitly broken." -- I'm curious to what extent this depends on what is or isn't an isolated heap (and how that various across browsers) -- in particular, does this risk more interop problems resulting from browsers having different ownership edges in their internal code (i.e., DOM API implementation) and different strategies (e.g., cycle collection) for dealing with those edges?

Since I wrote that statement, let me clarify: it's related to uses of WeakRefs by libraries, not internal browser implementations.
My concern is actually the same as yours above: cross-worker proxy libraries need to have a strong reference to a local object shared with a remote worker. Weak references and finalizers only help on the remote side and are not enough to allow collection of cycles that go across worker boundaries.\
So by "isolated heap" I was thinking mostly about workers (which may or may not be in the same process), but it could really be anything remote, even code on the server side.

For the specific worker with `postMessage` use case, I believe there is a way to remove the requirement for libraries to need WeakRefs and to hold a strong reference to the local object, with an extension of the postMessage mechanism. I need to write a proposal for it.

However the cycle problem is still valid outside of postMessage.\
I actually believe it's impossible to solve this problem without another mechanism allowing a library to know when it has full ownership of a currently unreachable slice of the object graph. I have an idea for a WeakRef follow-up proposal to introduce such a feature to JavaScript. You can find more details in an [issue I raised, including a very early version of that idea](https://github.com/tc39/proposal-weakrefs/issues/65).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/321#issuecomment-494498694