[concurrency-interest] DirectByteBuffers and reachabilityFence

David Holmes davidcholmes at aapt.net.au
Wed Dec 9 22:37:34 EST 2015


As far as I am concerned a key part of the JMM requirements surrounding
finalization has been omitted from the JLS. You may argue that HB is all
that is necessary to establish the requirement that finalize() can not
execute until after construction has completed, but that is far from clear
and I would not expect any JVM implementor to deduce that based purely on
HB. To me that is somewhat akin to inferring that monitors must enforce
mutual exclusion by only knowing about the HB edges defined for monitor
actions.

As I've stated the temporal constraint came first, and the adding of HB was
almost an afterthought to tidy up the model.

David

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
> interest-bounces at cs.oswego.edu] On Behalf Of Justin Sampson
> Sent: Thursday, December 10, 2015 12:25 PM
> To: Vitaly Davidovich; dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] DirectByteBuffers and
> reachabilityFence
> 
> Vitaly Davidovich wrote:
> 
> > The sane and intuitive thing is to say all reads/writes in ctor
> > happen-before all reads/writes in finalizer. That just about
> > enforces the temporal aspect but is also the model that all
> > developers would intuit.
> 
> That's exactly what the JLS says! Twice! It's central to the very
> definition of the happens-before ordering that the completion of a
> constructor happens-before the execution of a finalizer on the same
> object. That means _nothing but_ the fact that all reads and writes
> in the constructor happen-before all reads and writes in the
> finalizer. It doesn't say "_if_ the finalizer _doesn't_ execute
> concurrently with the constructor..." -- that would be meaningless,
> because the whole point of defining the happens-before ordering is
> to define the semantics of "concurrently." If one program action
> happens-before another, then they are by definition _not_ concurrent
> actions. Therefore the JLS explicitly states that no finalizer may
> ever be executed concurrently with any constructor for the same
> object. If by "temporal ordering" David means the order of actual
> instructions on a physical processor, that's an implementation
> detail -- all the JLS has to say is that the physical operation of
> the program must behave _as if_ all of the above is true. If a JVM
> does _not_ behave as if all of the above is true, then it is not
> implementing the JLS correctly.
> 
> Cheers,
> Justin
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list