RFR: 8272526: Cleanup ThreadStateTransition class [v2]
Patricio Chilano Mateo
pchilanomate at openjdk.java.net
Wed Aug 18 14:19:28 UTC 2021
On Wed, 18 Aug 2021 13:50:22 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> IIRC it was only the _thread_in_Java case that was special because that was where JIT'd code could have a series of unsafe memory accesses, and the exception won't be thrown until we hit a specific async exception check point.
>
> So today we always reach the _async_unsafe_access_error case of check_and_handle_async_exceptions() with a state of _thread_in_Java, except when called from jni_check_async_exceptions() where we are in vm, so I don't know why the message refers exclusively to compiled code. I run test InternalErrorTest.java in baseline with just the interpreter("main/othervm -Xint -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI InternalErrorTest") and still passes. Here is the code that sets the pending unsafe access error when the thread receives SIGBUS while in Java: https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L249
If the unsafe access error happens on Unsafe_CopySwapMemory0 like in the test then we will be either in vm or native (depending on src & dst) which will also output the same error message. We can differentiate between this cases if we want by saving the state in SharedRuntime::handle_unsafe_access().
-------------
PR: https://git.openjdk.java.net/jdk/pull/5128
More information about the hotspot-runtime-dev
mailing list