[jmm-dev] VarHandle.safepoint() methods

[Andrew Haley]

On 04/01/17 20:11, Sanjoy Das wrote:
> Hi Andrew,
> 
> On Wed, Jan 4, 2017 at 10:04 AM, Andrew Haley <aph at redhat.com> 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.
> 
> I presume you'll also want to prevent CSE across safepoints? That is:
> 
>   rA = t.getVolatile()
>   JVM::SafepointPoll()
>   rB = t.getVolatile()
> 
> =>
> 
>   rA = t.getVolatile()
>   JVM::SafepointPoll()
>   rB = rA
> 
> needs to be prohibited also?

Yes, absolutely.  I was assuming that the language I used was sufficient
to imply that.

Andrew.