Immediate closing of iterators
brendan at mozilla.org
Fri Dec 22 13:51:46 PST 2006
On Dec 22, 2006, at 1:23 AM, Chris Hansen wrote:
> I thought the guarantee was that an unreachable generator will
> eventually be closed. If you're using a conservative GC you may not
> be able to discover whether or not an object is dead and hence may
> keep dead objects alive indefinitely.
This is a "quality of implementation" issue, about which the spec
will not dictate.
Conservative GC in runtimes I'm familiar with works pretty well,
trading reduced risk of humans failing to manage the root set
correctly against risk of false positive. Such codebases use
classifying allocators pervasively, putting images and other non-
pointer data in unscanned allocations. The hard cases are the thread
stacks managed by good old C and C++, where the GC has no type
information. False positives are possible here, and they can cause
bloat, but it's bounded by the last-in-first-out discipline. If your
event loop has a float on the stack that aliases a pointer into the
heap, though, ....
> With a generational GC you may
> keep objects alive long after they're dead but at least you can, if
> you want, determine with certainty whether or not an object is dead.
> If you had a policy that caused a full collection to be run of all
> generations with some regularity (and the spec could mandate that) a
> generational GC could offer (what I thought was) the guarantee.
The spec is not going to mandate that; it's not the guarantee we're
> If, on the hand, the guarantee is that a generator will be closed
> before its space is reclaimed then using a conservative GC is still
> fine because the guarantee doesn't deal with generators that are not
> discovered to be garbage. But then is that a guarantee that is really
> useful to anyone?
Good question. We thought so, more on formal grounds to-do with try/
finally, than on practical grounds that don't hold up as soon as you
hypothesize code failing to call close on a generator and expecting
timely GC to call it. Anyone else care to weigh in?
More information about the Es4-discuss