[jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]
jvernee at openjdk.java.net
Thu Jul 15 12:41:33 UTC 2021
On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes <dholmes at openjdk.org> wrote:
> The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?
The main difference stems from the fact that, since these upcalls can come from non-JNI native code, we can not assume that the thread is already attached to the VM, so we do that on the fly instead, and we detach the thread again after the upcall (if needed). Those are what the call to `maybe_attach_and_get_thread` at the start of `on_entry`, and `detach_thread` call at the end of `on_exit` are for.
The other thing is that there is no stack watermark check at the end of `on_exit`. This check is guarded by a check if the thread has any pending exceptions in `JavaCallWrapper`, but since a panama upcall is not allowed to throw any exceptions, I've changed that to an `assert` that checks that there are no pending exceptions at that point instead.
The last thing is that we transition directly from `_thread_in_native` to `_thread_in_Java`, which changes some of the thread transition code.
Other than that, I've tried to mimic what `JavaCallWrapper` does as closely as possible.
Is there anything else that looks different?
More information about the hotspot-gc-dev