[Bug 10834] New: Garbage collection is the wrong level of abstraction

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10834

           Summary: Garbage collection is the wrong level of abstraction
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: excors@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


The spec talks about garbage collection with terms like "strong reference" and
"element to which no references exist" and "may the element be garbage
collected" and "This object must never be garbage collected" etc.

My understanding of the theoretical meaning of 'garbage' is that something is
garbage if the future operation of the program will not be observably affected
by whether that thing is destroyed or not (ignoring the observable effect of
running out of memory). That seems to match what
http://en.wikipedia.org/wiki/Garbage_(computer_science) talks about in the
introduction (then calls "semantic garbage"), and is equivalent to
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx (garbage
collection is simulating infinite memory - the mechanism is a separate
concern).

The concept of references is only relevant with a specific class of algorithms
that approximate garbage collection by counting or tracing references. The spec
seems to assume to assume some algorithm like this, without actually saying so
(as far as I can see), which makes the mentions of GC confusing and weird.

In particular, the observable behaviour is unclear. If the behaviour of the
browser's GC implementation has observable effects, then that's theoretically
wrong (it must have cleaned up something that wasn't truly garbage) and likely
very confusing for authors (since many GC implementations are
non-deterministic) and an interoperability danger. If there's no observable
effect, then the discussion doesn't belong in normative sections of the spec
(it's just an implementation quality issue, like any other aspect of
performance or resource limits).

If the GC behaviour should be observable, I think the spec ought to add notes
pointing out how it can be observed, so that it's clear the behaviour is worth
specifying normatively and so that authors know what to look out for. In that
case the spec should also define what basic model of GC it's using when
defining the behaviour, so that it makes sense.

If the GC behaviour should not be observable, I think the spec shouldn't say
anything normative about it, but it could have non-normative notes to
implementers to remind them that they mustn't collect the object yet because
that collection could be observed (and mention how).

In both cases, the important thing is the observable behaviour that users can
experience, not the mechanics of garbage collection.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 September 2010 16:39:28 UTC