- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 12 Aug 2013 18:24:39 +1000
- To: Device APIs Working Group <public-device-apis@w3.org>
On Sat, Aug 10, 2013 at 4:54 AM, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > DAP-ISSUE-136: Issues related to garbage collection [Network Service Discovery] > > http://www.w3.org/2009/dap/track/issues/136 > > Raised by: Frederick Hirsch > On product: Network Service Discovery > > issues on garbage collection raised by Adam Barth > > https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/network$20service$20discovery/blink-dev/HT0KZKuTLxM/S3w-SdvjZfUJ > > 2) The requirements in the garbage collection section seem quite onerous and unlikely to be correct. There area a number of problems with these requirements: > > a) The specification states that a certain object must not be garbage collected until the user navigates away from a particular origin. Chrome uses a multiprocess architecture in which a given origin might be present in multiple processes. If we implemented this requirement, we might need to keep a process alive just to avoid garbage collecting this object if the user happened to be viewing another page from the object's origin in another process. Even if this requirement were scoped to a given process, this requirement would still cause use to keep the object alive much longer that reasonable, effectively leaking resources. > > b) The specification requires that we garbage collect certain objects at the same time that we garbage collect certain other objects. It's not clear to me what the author of that requirement intended, but, as written, the requirement is problematic: > > i) The requirement mandates a finalizer for the NetworkService objects that can change a web-visible property from true to false, giving scripts the ability to detect when garbage collection occurs. We've carefully avoided giving scripts this visibility into the internal details of the garbage collector to avoid having to mimic garbage collector quirks across user agents. > > ii) It's not clear what behavior the user agent is required to exhibit if script keeps a reference to a NetworkService object but does not keep a reference to the corresponding NetworkServices object. Perhaps the requirement would better be phrased as forbidding collection of the NetworkServices object in this situation rather than mandating the garbage collection of the NetworkService object? As written, this requirement would leave script with a reference to an object that had already been garbage collected, violating a basic invariant of the garbage collector. I've re-written this section of the specification. This section as previously written was indeed too onerous as Adam points out above. The rewrite aims to convey the relationship between NetworkServices objects and their 'indexed properties' rather than mandating that these objects always be garbage collected together. The specification now states that there is a strong reference from NetworkServices objects towards its indexed properties (NetworkService objects) and an implied weak reference from NetworkService objects to NetworkServices objects. I have also borrowed heavily from other specifications wrt 'make disappear' terminology rather than tying garbage collection directly to an entry script's origin. That was clearly not the right behavior previously. If any further clarifications are required wrt garbage collection please let me know. This should now be much more in line with garbage collection requirements provided in other specs. A diff containing the fixes can be viewed online @ https://dvcs.w3.org/hg/dap/diff/b4b2569b4e9b/discovery-api/Overview.src.html. br/ Rich
Received on Monday, 12 August 2013 08:25:05 UTC