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