dl at cs.oswego.edu
Fri Aug 15 00:22:14 UTC 2014
On 08/13/2014 07:11 PM, Hans Boehm wrote:
> You're suggesting that if a method accesses an @Finalized field (including
> passing it to other methods), then all reference variables in that method are
> kept around until the end of their scope?
I'm suggesting something slightly simpler. A reachabilityFence(x)
is placed/checked after each access of @Finalized field x.r.
No other JLS changes.
This suffices even for lambdas used in async constructions, but not
(without some visible surgery) in some other forms of async
usage, as in my Thread/Runnable version.
> Presumably returning an @Finalized field from a public method yields at least
> a warning?
Even with these kinds of limitations, this approach seems
to cover more ground than any other proposal.
Still, the limitations seem to place it more in the realm of
tools than languages.
> Unfortunately declaring a finalizer without an @Finalized field probably has
> to be OK to cover the finalizers that just report leaks.
> That sounds like it might be workable, if this is considered an acceptable
> use of annotations. Leaving it off subtly breaks code.
I don't think it "breaks" anything. Code without it would still
be subject to the (revised) JLS sec 6.12 rules. Code with it would
be much harder to get wrong. A second-order checker could suggest
its use for any field accessed in a finalize() method.
Also (out of order...)
> Especially for the
> second version (what do lambdas actually capture in the first case?),
The lambda specs give some latitude, but as a quality of
implementation matter, compilers capture as little context as
they legally can. If "resource" were a final field, then its
holder wouldn't necessarily be captured. But it might be.
More information about the jmm-dev