[concurrency-interest] DirectByteBuffers and reachabilityFence

Gil Tene gil at azul.com
Wed Dec 9 23:20:12 EST 2015

As I note elsewhere, I think the missing requirement is for instances to remain reachable as long as any of their instance methods are executing. Since that includes constructors, it would completely eliminate the whole constructor/finalizer ordering discussion without making it a HB or ordering thing.

Fixing just the constructors, and just for finalizers wouldn't be of much use. Most things that have a constructor/finalizer race issue would also have races with other instance methods, and for many finalizer race issues you can find an equivalent/similar cleaner (or other phantom/weak/soft ref) issue.

Sent from Gil's iPhone

> On Dec 9, 2015, at 7:59 PM, David Holmes <davidcholmes at aapt.net.au> wrote:
> 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
> _______________________________________________
> 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