RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives

[Roman Kennke]

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).

PR: https://git.openjdk.java.net/jdk/pull/1349