Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

On Tue, Feb 8, 2011 at 10:36 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Feb 8, 2011 at 9:26 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Tue, Feb 8, 2011 at 3:36 AM, João Eiras <joao.eiras@gmail.com> wrote:
> >>
> >> > Unless by "certain GC behavior" mean
> >>
> >> I referred to
> >>
> >> # The only solution I can think of is to require (or recommend) that
> >> implementations run the garbage collector
> >>
> >> The GC is transparent and a spec cannot expect that it runs at
> >> specific times or demand it.
> >
> > Yeah, Jonas.  We can't reasonably expect any behavior from the garbage
> > collectors.  I can't think of any other precedent for this.  And as
> > collectors become more complicated, doing a gc that catches _every_ piece
> of
> > garbage is becoming harder or even impossible (not aware of any GC's
> where
> > it is "impossible" in specific cases, but it wouldn't surprise me).  The
> v8
> > guys simply won't let us do this.  :-)
> > And saying that at the worst case your setVersion transaction will stall
> > possibly forever just doesn't seem like a good solution either.
>
> Huh? It seems like a very strange GC implementation that not only
> doesn't allow you to do a full search for garbage, even
> asynchronously, but then can't even guarantee that a given object will
> eventually be freed.
>
> I'm all for not relying on GC behavior, but not even relying on it to
> collect garbage? That seems a bit extreme to me. It's also not a GC
> strategy I've ever heard of, so yes, it would surprise me if there are
> GC strategies out there that doesn't free up objects sooner or later.
> How is that different from a GC strategy that is simply leaking?
>

I meant that it wouldn't be able to collect on demand like that.  Or that it
would at least be prohibitively expensive.


> > What if we made the default for onsetversion to be calling close?  I.e.
> > instead of the close behavior being opt-out, it'd be opt-in?  I know we
> made
> > a conscious decision originally of it being opt-in, but I don't see how
> > that'll work.
>
> This flips the model completely on its head since you're now forced to
> implement a more advanced version upgrade strategies or suffer your
> pages breaking.
>
> The worst case scenario isn't even that bad IMHO. Say that you have a
> GC strategy which truly never frees the unreferenced DB object. That
> is no worse than the page simply holding a reference DB object and
> making the version upgrade wait for the user to close old tabs.
> Something that is bound to happen anyway if authors take the simple
> path of not listening to "blocked" or "versionchange" events.
>

You're assuming implementations have one heap per tab.

We could cheat and kill things when the document goes away, I suppose.
 Still not very excited about that tho.  (Especially since even those
semantics can be a bit tricky, at least in WebKit.)

I'd like to hear other peoples' thoughts on this.

J