[jmm-dev] VarHandle.safepoint() methods

[Andrew Haley]

On 04/01/17 21:04, Doug Lea wrote:
> On 01/04/2017 01:04 PM, Andrew Haley wrote:
>> This is a proposal for a new VarHandle method, but it also is an
>> extension to the Java Memory Model, so I'm starting the discussion
>> here.
>>
>> My intention is to provide an efficient way to handle the case where a
>> field has reads which outnumber writes by several orders of magnitude.
>> Once a field has been successfully modified, no thread may observe a
>> stale value.  Writes to a field are expected to be very rare, and can
>> be expensive.
>>
>> It provides a secure and fast way to do something like a volatile
>> access but without any memory fences (or even any restrictions on
>> memory reordering) on the reader side.
>>
>> I propose two new VarHandle methods:
>>
>> Object getSafepoint()
>>
>>   Returns the value of a variable, with memory semantics of reading as
>>   if the variable was declared non-volatile, except that this load
>>   shall not be reordered with a preceding safepoint.
>>
> 
> Just to make sure we agree on interpretation before further
> contemplating this:
> 
> The intent is to act as plain get(), except that that upon
> safepoint exit, it must act as a getAcquire().  And further that it
> need not be treated as getAcquire after safepoint check that does
> not result in a safepoint execution?

That's right.

> And the motivation for doing this is to allow compilers to split paths
> within loops and other cases where caching in a register would be a big
> win because the values are heavily used and safepoints rarely trigger.

That's right too.

Andrew.