[jmm-dev] VarHandle.safepoint() methods
aph at redhat.com
Thu Jan 5 09:27:01 UTC 2017
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
>> 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?
> 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.
More information about the jmm-dev