Bug ID: JDK-8257996 NativeLibraryTest.java still fails intermittently after JDK-8200102

Type: Bug
Component: core-libs
Sub-Component: java.lang:class_loading
Affected Version: 16

Priority: P4
Status: Open
Resolution: Unresolved

Submitted: 2020-12-09
Updated: 2021-06-30

Other
tbdUnresolved

Even after fix for JDK-8200102 the test is still failing:

#section:main
----------messages:(4/195)----------
command: main -Xcheck:jni NativeLibraryTest
reason: User specified action: run main/othervm/native -Xcheck:jni NativeLibraryTest 
Mode: othervm [/othervm specified]
elapsed time (seconds): 0.313
----------configuration:(0/0)----------
----------System.out:(11/55)----------
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
gc 0
----------System.err:(13/837)----------
java.lang.RuntimeException: Expected unloaded=2 but got=1
	at NativeLibraryTest.main(NativeLibraryTest.java:71)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:831)

Being "on the stack" is not sufficient to guarantee reachability, in theory, in general.
17-02-2021
[~dholmes] during the execution of ForceGC::await, ForceGC instance is on the stack and still reachable. So the object is strongly reachable until await returns. Are you thinking ForceGC is being escaped during the execution of await?
16-02-2021
Sorry I did not realise that later "strange log" was missing the fix for 8258007. However I think my analysis remains valid: if the ForceGC instance is not itself strongly reachable then neither is the the object.
02-02-2021
> One more failure with even more strange log: > java.lang.RuntimeException: Expected unloaded=2 but got=2 The "strange" log indicates we're racing with the cleaning logic and while the unloading did not occur within the gc.await() timeframe, it happened shortly after and before we constructed the exception message that read the unloadedCount. The elapsed time of 1.4 seconds shows that we are returning "early" from gc.await (ie looping all 10 times in quick succession) because the latch has been signalled, indicating that the object registered with the cleaner has been GC'd much earlier than expected. If the ForceGC instance is itself not strongly reachable (and having a call to await() in progress does not make it strongly reachable!), then both the ForceGC instance and the internal Object can be GC'd earlier than naively expected by the code using the ForceGC instance. I suggest changing the test so that the ForceGC object is referenced from a static field, not a loop-local.
02-02-2021
[~dholmes] are you referring to a test failure with this output: gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 gc 0 java.lang.RuntimeException: Expected unloaded=2 but got=2 at NativeLibraryTest.main(NativeLibraryTest.java:71) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) The above output does not have the fix for JDK-8258007.
28-01-2021
AFAICT we haven't seen any failures since JDK-8258007. I'm going to leave this open for now, just in case, but reduce the priority again.
07-01-2021
Hopefully we'll see some improvement from JDK-8258007.
19-12-2020
Based on the log, it looks like that the latch is zero when the first doit is called. It's possible if the object registered in the cleaner is GC'ed before ForceGC::await is called. It should keep a strong reference to the object registered in the cleaner and release the reference when await is called.
18-12-2020
Bumped the priority from P3 -> P2 since this failure has appeared in a couple of Tier1 job sets.
18-12-2020