Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases

2011/2/8 Jeremy Orlow <jorlow@chromium.org>:
> 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.

That I can understand, which is why I said "or recommend". I suspect
that in firefox it will get harder to do a synchronous GC, but a
asynchronous one seems like it will remain possible. But even if you
don't do anything, we'll always end up running GC at *some* point.

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

Not at all. I'm just assuming GC will run in all heaps at some point.

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

Wait, you're worried that you won't even run GC once the user leaves
the page? I thought that in that case chrome just killed the process.
Surely that will close any open databases?

/ Jonas

Received on Tuesday, 8 February 2011 19:58:18 UTC