UnsafeAtomicityTest crashes on SPARC (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Oct 30 14:06:09 UTC 2015

I see.

Yes, I would think intercepting SIGBUS and failing with InternalError is a marginally better JVM behavior, especially if it says something like "Unrecoverable misaligned unsafe access, bye".

Let's see what runtime devs think about this?

-Aleksey

On 10/30/2015 04:02 PM, Doerr, Martin wrote:

Hi Aleksey,

exactly, the putInt(offset, 0xFFFFFFFF) improves the situation. It uses DEFINEGETSETNATIVE which calls setdoingunsafeaccess before the access while the other one uses DEFINEGETSETOOP which doesn't do that (see unsafe.cpp). The JVM will usually not run much longer after the SIGBUS was caught because setpendingunsafeaccesserror() gets called afterwards which should eventually lead to JVM exit with the asynchronous java.lang.InternalError exception (unless one catches it which is rather uncommon). Best regards, Martin

-----Original Message----- From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com] Sent: Freitag, 30. Oktober 2015 13:06 To: Doerr, Martin Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: UnsafeAtomicityTest crashes on SPARC * PGP Signed by an unknown key Hi Martin, Thanks for a heads-up. On 10/30/2015 02:52 PM, Doerr, Martin wrote: we have seen JVM crashes when running the following test on SPARC: org.openjdk.jcstress.tests.vjug.UnsafeAtomicityTest

Maybe it is not supposed to run on platforms which don't support unaligned accesses? Yes, unaligned Unsafe access might crash on platforms that do not support unaligned accesses. The test should have checked Unsafe.unalignedAccess() and/or used Unsafe.putIntUnaligned. Both APIs are not available in JDK 8, though. I see 2 problems: 1. The current implementation uses the version of UnsafeHolder.U.putInt(null, offset, 0xFFFFFFFF) (and getInt) which is designed to access object fields. Seems like the JVM is allowed to crash with SIGBUS if it is misused for unaligned accesses. The JVM is designed to catch SIGBUS only in the other version which only takes the address UnsafeHolder.U.putInt(offset, 0xFFFFFFFF). This is an odd difference. So, nominally, making the test to use putInt(offset, 0xFFFFFFFF) avoids the issue? 2. The signal handler in ossolarissparc needs a fix to catch BUSADRALN as well. The part "&& info->sicode == BUSOBJERR" of the condition "if (sig == SIGBUS && info->sicode == BUSOBJERR && thread->doingunsafeaccess())" should get removed as it was done on other platforms. With the problems fixed, it may be possible to catch the asynchronous exception which may get generated by the Unsafe access. The following stand-alone test program below can do it. Yes, I think runtime folks might consider bullet-proofing this. Although I sometimes see the SIGBUS as a viable alternative for a creeping performance problem, at least in testing. (IIRC, some kernels are known to silently fix up this as well). Thanks, -Aleksey * Unknown Key * 0x62A119A7

More information about the hotspot-runtime-dev mailing list