[jmm-dev] Non-core-model issues status

[Andrew Haley]

On 20/10/14 22:01, Hans Boehm wrote:
> I can see arguments for putting the annotation on
> 
> 1) A field that is logically invalidated by finalization, implying that
> reachability of the enclosing object needs to be preserved as long as it is
> logically reachable.
> 
> 2) The class that contains such a field.
> 
> I think (1) has the advantage that we can restrict the more careful
> treatment to methods accessing that field rather than all methods.  (2) may
> be slightly simpler to use.
> 
> As Paul suggests, we could also (3) annotate the methods accessing such a
> field.  That seems less convenient and more error-prone to me.  In
> particular, for something like Android BigInteger, we'd end up annotating
> most of the methods, rather than either a single field or a single class.
> It does seem better to me than explicit reachabilityFence(), which would
> require dozens of much more subtle (and largely untestable) annotations.

It seems better to me too, but as I understand it any annotation would
be expanded by javac to a try { ... } finally { reachabilityFence(); }
or something similar.  In that case it makes sense to make
reachabilityFence() part of a public API, even if only for the non-
Java languages running on the JVM who are equally plagued by early
finalization.

Andrew.