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

[Aleksey Shipilev]

On Mon, 23 Nov 2020 19:06:21 GMT, Roman Kennke <rkennke 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!

Thanks!

-------------

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