RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives
rkennke at openjdk.java.net
Mon Nov 23 19:08:58 UTC 2020
On Fri, 20 Nov 2020 14:23:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71).
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217
> # assert(handle != __null) failed: JNI handle should not be null
> It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test.
> Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations.
> Additional testing:
> - [x] Affected test with Zero (+Epsilon, +Shenandoah)
> - [x] Affected test with Server (+Epsilon, +Shenandoah)
Looks good to me! Thanks!
Marked as reviewed by rkennke (Reviewer).
More information about the hotspot-gc-dev