RFR (S): 8186787: clang-4.0 SIGSEGV in Unsafe_PutByte
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Nov 27 18:27:07 UTC 2017
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