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