- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 8 Feb 2011 11:57:25 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Joćo Eiras <joao.eiras@gmail.com>, public-webapps <public-webapps@w3.org>
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