Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

In some cases we leak them, yes (they live for the life of the parent
context) if the developer does not close them. Typically this is only when
you've cloned a MessagePort and sent the other end to a different process.
Trying to figure out if a port is reachable when the entangled port lives in
a different process (and whose reachability may itself depend on the
reachability of a third port in yet another process ad infinitum) is a
fairly intractable problem.

This does not happen with the implicit ports associated with dedicated
workers, because in WebKit those aren't actually MessagePorts (mainly
because the webkit implementation of dedicated workers predates message
ports). Chromium SharedWorkers use real MessagePorts though, so if you do
this:

var w = new SharedWorker("foo.html");
w.port.onmessage = function() {...};

that port will not be GC'd in chromium, even if the SharedWorker drops its
end of the port on the floor, until either the SharedWorker calls close() on
the port, the worker exits or your parent document is collected.

On a related note, please see this statement from section 5.5 of the
MessagePort spec:

Authors are strongly encouraged to explicitly close
MessagePort<http://dev.w3.org/html5/postmsg/#messageport> objects
to disentangle them, so that their resources can be recollected. Creating
many MessagePort <http://dev.w3.org/html5/postmsg/#messageport> objects and
discarding them without closing them can lead to high memory usage.

-atw

On Wed, Feb 9, 2011 at 12:56 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson <atwilson@google.com> wrote:
>
>> This discussion reminds me of a similar issue with MessagePorts. The
>> original MessagePort spec exposed GC behavior through the use of onclose
>> events/closed attributes on MessagePorts. It turns out that on Chromium,
>> there are situations where it's very difficult for us to GC MessagePorts (a
>> port's reachability depends on the reachability of the entangled port on an
>> entirely separate process), and so we just don't.
>
>
> Err, so you just leak MessagePorts?  Or just in those situations, whatever
> they are?  Does this happen even for the implicit MessagePort associated
> with each worker?
>
> --
> Glenn Maynard
>