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

Erik Österlund erik.osterlund at oracle.com
Tue Nov 28 12:27:28 UTC 2017


Hi Coleen,

On 2017-11-27 19:27, coleen.phillimore at oracle.com wrote:
>
> I think this is a nice simple fix and should be pushed for JDK10.

Thank you for the review.

/Erik

> 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