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

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

--- Comment #2 from Philip Taylor <excors@gmail.com> 2010-09-29 20:35:55 UTC ---
Unless I'm significantly misunderstanding things:

The fact that you can refer to the document through ownerDocument means there's
already necessarily a reference - otherwise you couldn't refer to it. The
implementation can't magically grab the object out of thin air when you access
ownerDocument, it has to already have a chain of references to reach it.

There's no reason for it to ever automatically turn into null, unless it was
specifically implemented with a weak reference that intentionally turns into
null at some possibly non-deterministic time when there's currently no strong
references, and it shouldn't be implemented like that unless it's specified
like that, and I don't think it's specified like that anywhere.

What matters to the spec is simply that it is possible to access the document
via ownerDocument, which means the document is not garbage (by the theoretical
definition of garbage). It's a low-level implementation detail that the
this-is-not-garbage status will be determined by the presence of references,
and there's no reason for the spec to care about that specific implementation
detail and not the billion other implementation details in a browser.

Having the spec mention half a dozen places where there are strong references
is also pointless when e.g. the entire ES5 spec seemingly doesn't mention
garbage collection even once, so nothing explicitly defines that if you write
"var d = e.ownerDocument;" you've got a strong reference at that point. It
would only be meaningful if the reference graph (and root set) of the entire
web platform was specified, otherwise there's just a few specified references
dangling in a giant ocean of undefinedness.

(Hypothetically you could have a null garbage collector that does nothing, or a
future-predicting oracle (perhaps based on a log replay) that collects objects
precisely after the last time you read them (even if there's still some
references). Less hypothetically, you could have a fancy JITted browser that
statically analyses the code to realise a script has an Element variable but
only ever accesses tagName so it's free to collect all the other properties
immediately, even though it looks like the script still has a reference to the
Element.)

-- 
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 20:35:58 UTC