- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Sep 2010 16:39:24 +0000
- To: public-html@w3.org
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 on the CC list for the bug.
Received on Wednesday, 29 September 2010 16:39:28 UTC