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

[Hans Boehm]

Sounds reasonable to me.  So long as there is a reasonably clean and
straightforward way to write the Java source code in 99% of use cases, I'm
happy.  I think reachabilityFence() by itself, without the annotation,
doesn't get us far enough.

On Wed, Oct 22, 2014 at 1:42 PM, Andrew Haley <aph at redhat.com> wrote:

> 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.
>