On Thu, 8 Sep 2022 20:26:41 GMT, Roger Riggs <[email protected]> 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
