Re: DAP-ISSUE-136: Issues related to garbage collection [Network Service Discovery]

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