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

David Holmes david.holmes at oracle.com
Tue Nov 28 06:41:06 UTC 2017


+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
> 


More information about the hotspot-runtime-dev mailing list