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