Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

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?

> 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.

/ Jonas

Received on Tuesday, 8 February 2011 18:38:09 UTC