RFR: 8293282: LoadLibraryUnloadTest.java fails with "Too few cleared WeakReferences"
Jaikiran Pai
jpai at openjdk.org
Fri Sep 9 03:40:38 UTC 2022
On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
> Modify the LoadLibraryUnload test to call gc() more a few times, allowing multiple gc cycles to queue the expected refs.
> Short the timeout on each cycle to 10 sec.
Hello Roger, just a few additional points that I noticed about this test. I haven't fully investigated to see if they play any role at all, but I thought I will note them here:
- The `LoadLibraryUnloadTest` which acts as a driver, launches the `LoadLibraryUnload` as a Java program. There's no specific memory settings passed when that program is launched (line 82 of `LoadLibraryUnloadTest`). I did a quick test a few days back where I updated the process builder launch command to use `-XshowSettings:all` to see what the inferred memory setting would be for this program on our CI systems and I could see that in many cases the estimated max heap size was as big as 7G:
[0.001s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k
[0.002s][info ][gc] Using G1
[0.002s][debug][gc] ConcGCThreads: 2 offset 16
[0.002s][debug][gc] ParallelGCThreads: 8
[0.002s][debug][gc] Initialize mark stack with 4096 chunks, maximum 524288
VM settings:
Max. Heap Size (Estimated): 7.75G
Using VM: Java HotSpot(TM) 64-Bit Server VM
So, would it be relevant/useful if the driver launched the `LoadLibraryUnload` with a more specific/lesser value of max heap size?
- The driver `LoadLibraryUnloadTest` is launched using `-Xcheck:jni` in its test definition. Looking at the code of `LoadLibraryUnloadTest`, I'm unsure why that would be needed on the test definition. I am wondering whether that `-Xcheck:jni` should have instead been passed to the process builder launched `LoadLibraryUnload` process, which is where the actual JNI usage is taking place. Of course this isn't what is causing the test failures.
-------------
PR: https://git.openjdk.org/jdk/pull/10223
More information about the core-libs-dev
mailing list