[jmm-dev] constructor releases (was: ECOOP, JVMLS)

[Doug Lea]

On 08/06/2014 12:04 PM, Doug Lea wrote:
> On 08/05/2014 01:56 PM, Hans Boehm wrote:

>> I'm still apprehensive about relaxing the final field rules.  I'll
>> withhold judgment until I see what we actually come up with.
>
> For the sake of your main concerns, I think it suffices to just assume it
> takes the form of a guaranteed C++/C11 memory_order_release fence upon
> constructor exit.
> ...

> Here, I'm not sure who would be surprised that if a constructor accesses
> non-local state, then without care, there are few/weak reader-side
> guarantees.
>
>> It was the reader-side constraints that would have slowed down a DEC alpha
>> implementation.  Although Alpha doesn't matter any more, that's still
>> where the issues are.
>>
>> The down side is that such a change seems to sanction this kind of racy
>> programming, while leaving plenty of traps like the array example above.
>> Paul, Torvald et al, have spent some time looking at this in the context of
>> RCU in the Linux kernel, and ordering for field references doesn't seem to
>> cover nearly all the cases that people actually expect to work.
>
> Paul: Can you summarize?

Lacking a summary, I found ...

* The most recent linux memory barrier documentation
   https://www.kernel.org/doc/Documentation/memory-barriers.txt

* Paul's paper on implementing memory_order_consume
   https://isocpp.org/files/papers/n4036.pdf

... which do seem to defy a simple summary. Despite this,
my take on it continues to be that release-on-construct
is to useful and cheap not to do, even though it does
not cause code to become miraculously correct when origins
of loads made visible from reading "this" are uncontrolled.

-Doug