RFR (S): 8186787: clang-4.0 SIGSEGV in Unsafe_PutByte

[Erik Österlund]

Hi David,

Thanks for the review.

/Erik

On 2017-11-28 07:41, David Holmes wrote:
> +1
>
> David
>
> On 28/11/2017 4:27 AM, coleen.phillimore at oracle.com wrote:
>>
>> I think this is a nice simple fix and should be pushed for JDK10.
>> Thanks,
>> Coleen
>>
>> On 11/27/17 7:36 AM, Erik Österlund wrote:
>>> Hi,
>>>
>>> There is currently a bug when using unsafe accesses off-heap:
>>>
>>> 1) We write into a thread that we enable crash protection (using 
>>> GuardUnsafeAccess):
>>> 2) We perform the access
>>> 3) We write into a thread that we disable crash protection (using 
>>> ~GuardUnsafeAccess)
>>>
>>> The problem is that the crash protection stores are volatile, but 
>>> the actual access is non-volatile. Compilers have different 
>>> interpretation whether volatile - non-volatile accesses are allowed 
>>> to reorder. MSVC is known to interpret such interactions as-if the 
>>> volatile accesses have acquire/release semantics from the compiler 
>>> point of view, and others such as GCC are known to reorder away freely.
>>>
>>> To prevent any issues, the accesses involved when using 
>>> GuardUnsafeAccess should be at least volatile.
>>> This change makes the few remaining ones volatile. The JMM-volatile 
>>> (SEQ_CST) accesses with crash protection already have stronger 
>>> ordering than volatile and hence do not need changing.
>>>
>>> By making the address passed in to the Access API volatile, the 
>>> MO_VOLATILE decorator is automatically set, which not surprisingly 
>>> makes the access volatile. Therefore, the solution is to simply make 
>>> the address passed in to Access volatile in this case.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8186787
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8186787/webrev.00/
>>>
>>> Thanks,
>>> /Erik
>>