On 03/20/2014 01:39 AM, Kyle Huey wrote:
Followup to dev-platform please.

We are discovering a lot of leaks in JS implemented DOM objects.  The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong references to the
listener.  In C++ we would split the object into two separate
refcounted objects, one for the DOM side and another that interfaces
with these global singletons (which I'll call the proxy).  Between
this pair of objects at least one direction would be weak, allowing
the DOM object's lifetime to be managed appropriately by the garbage
and cycle collectors and in its destructor it could tell the proxy to
unregister itself and die.  But this isn't possible because of the
lack of weak references in JS.

Instead we end up running a bunch of manual cleanup code at
inner-window-destroyed.  This is already bad for many things because
it means that our object now lives for the lifetime of the window
(which might be forever, in the case of the system app window on B2G).
  Also in some cases we forget to remove our inner-window-destroyed
observer so we live forever.  For objects not intended to live for the
lifetime of the window we need to manually perform the same cleanup
when we figure out that we can go away (which can be quite difficult
since we can't usefully answer the question "is something in the
content page holding me alive?").  All of this requires a lot of
careful manual memory management which is very easy to get wrong and
is foreign to many JS authors.

Short of not implementing things in JS, what ideas do people have for
fixing these issues?  We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at inner-window-destroyed
to provide a good cleanup hook that is not global) but that doesn't
help with objects intended to have shorter lifetimes.  Is it possible
for us to implement some sort of useful weak reference in JS?

I'm rather strongly against adding weak refs to the web platform.
They expose GC behavior, which lead to odd and hard to debug errors,
and implementations may have to use pretty much the same GC.

Internally we have weakref support in WrappedJS, and one can use
weak observers for ObserverService and weak listeners for MessageManager.
Aren't those not enough for the cases where weakrefs anyway can help?
We could use WrappedJS also in some kind of chrome Promises - WeakPromise,
which wouldn't keep the callback alive.


-Olli



_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to