[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 9 15:59:45 EST 2015


Yes, I understand the meaning of happens-before.  My point, however, is
that specifying things this way but not actually mandating that finalizer()
runs after all load/store operations in the constructor have occurred is
meaningless (and "hostile" towards developers) - it would be impossible to
reason reliably about anything in the finalizer.

On Wed, Dec 9, 2015 at 3:51 PM, David Holmes <davidcholmes at aapt.net.au>
wrote:

> By having construction happen-before finalization, it ensures that if
> finalization happens after construction is complete then it will see all of
> the constructed values, even though they happened in a different thread.
> This is normal happens-before with regard to two synchronization actions –
> but a construction is not a synchronization action it was special-cased.
>
>
>
> David
>
>
>
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *Vitaly
> Davidovich
> *Sent:* Thursday, December 10, 2015 1:36 AM
> *To:* dholmes at ieee.org
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] DirectByteBuffers and
> reachabilityFence
>
>
>
> sent from my phone
>
> On Dec 9, 2015 6:11 AM, "David Holmes" <davidcholmes at aapt.net.au> wrote:
> >
> > Andrew Haley writes:
> > > On 09/12/15 09:21, David Holmes wrote:
> > >
> > > > The happens-before requirement was deliberately set the way it is to
> > > > show that an object can not be finalized before its construction has
> > > > completed (whether normally or abnormally). So I would agree with
> > > > Justin that it should not be possible for an object to be finalized
> > > > before construction has completed - regardless of potential compiler
> > > > optimizations etc.
> > >
> > > Hmmm, okay.  It might be that I misremembered or perhaps it was a bug,
> > > but I don't think so.  Is there really a happens-before relationship
> > > between a constructor of an object with no volatile or final fields
> > > and its finalizer?
> >
> > My recollection - and I've been trying to find this in the
> JavaMemoryModel
> > archives - is that the happens-before between constructor and finalizer
> was
> > introduced because the normal "trick" of using synchronization was very
> > counter-intuitive in constructors given the object has not been
> published.
> >
> > That said, A happens-before B simply establishes visibility/ordering
> rules
> > for the case when A occurs before B. It says nothing about B occurring
> > before A, or B and A overlapping. Other mechanisms have to force the
> > temporal order. So it may be I misspoke my support of Justin's position.
> :(
>
> I have a different interpretation, akin to your previous answer.  There's
> very little point in stating that ctor happens-before finalization if
> that's not even the case always (i.e. they overlap or occur in reverse
> order) - how would that be meaningful?
>
> >
> > David
> > -----
> >
> >
> > > Andrew.
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > Concurrency-interest at cs.oswego.edu
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/7300f172/attachment.html>


More information about the Concurrency-interest mailing list