Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

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.

My concern is that there may be situations like this with IDB - if at some
point it's possible for events to be fired on an IDB instance (if we support
triggers), you'll have a situation where the reachability of an IDB instance
may depend on the reachability of that same DB in other processes. The net
effect is that on multi-process/multi-heap platforms, we may not be able to
GC databases, while on other platforms (which have a unified heap) we will
be able to GC them. This will end up being a source of cross-browser
incompatibility, because code will work just fine on platforms that are able
to deterministically GC databases, but then will break on other platforms
that cannot.

(As an aside, Jeremy mentions that there may already be situations where we
cannot GC databases today - I don't know the spec well enough to comment,
though, so perhaps he can elaborate).

In any case, I don't think that IDB should be the first place in the entire
web platform where we expose GC behavior to clients.

-atw

On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >>
> >> I talked it over with Darin (Fisher), and he largely agreed with you
> guys.
> >>  I'll file a bug saying that after unload, all IDBDatabases attached to
> that
> >> document should be closed.
> >
> > What happens if a database is open in a page in the back-forward cache?
> > That's incompatible with onunload having side-effects.
> >
> > I know the BF-cache is off-spec, but it's extremely useful and will
> > hopefully find its way into the standard some day, so it'd be nice to
> keep
> > it in mind.
> >
> > I suppose the browser would discard whole pages from the BF-cache on
> demand
> > if required by a setVersion call.
>
> That's exactly what we do in Firefox. Implementations have to be able
> to throw things out of the BF cache on command anyway (since you
> generally want to limit the number of pages living in BF cache, and so
> loading a new page often causes other pages to be thrown out), so it's
> just a matter of calling into the same code here.
>
> / Jonas
>
>