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