[concurrency-interest] DirectByteBuffers and reachabilityFence
boehm at acm.org
Wed Dec 16 20:57:16 EST 2015
My vague recollection is also that there should have been a statement
preventing finalization before constructor completion. I'm actually no
longer sure how much it matters. I think 12.6.2 ensure that the finalizer
must see all non-finalizer writes to the object. Thus I think it must see
an object that looks more or less initialized. In the new world, basically
every method, probably including the constructor, that uses a field cleaned
up by a finalizer should use an explicit reachabilityFence.
I suspect that in the long run we essentially just want to say that the
last reachabilityFence happens before the finalizer, and lose the rest of
12.6.2. Almost no finalizer works without reachabilityFence anyway.
Note that "this" is really not special here. A great (bad?) example is
Android's BigInteger implementation that wraps a native bignum
implementation. The finalizer deallocates the native object. If you look
at something like the add() method, "this" and the method argument are
entirely symmetric. Either would be subject to premature finalization of
we didn't work around the issue in the compiler.
On Thu, Dec 10, 2015 at 1:06 PM, David Holmes <davidcholmes at aapt.net.au>
> David M. Lloyd writes:
> > On 12/09/2015 07:44 PM, David Holmes wrote:
> > > To be clear, I missed this later assertion:
> > >
> > >> In summary, we agree that an object can _become finalizable_ before
> > >> completion of its constructor, if the Object constructor completed
> > >> normally and the object is otherwise no longer reachable.
> > >
> > > No! The object should not be able to become finalizable until after
> > all its
> > > constructors have completed, and then it becomes unreachable.
> > Is this your view of the existing world, or what you are proposing be
> > changed? I'm losing track of what's what in this discussion. :-)
> This is how the existing world should have been if the JLS update had not
> been snafu'd. Justin would argue it should be the current state regardless
> due to happens-before definition. Regardless the JVM does not currently
> implement this.
> David H.
> > --
> > - DML
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest