[jdk18] RFR: 8279597: [TESTBUG] ReturnBlobToWrongHeapTest.java fails with -XX:TieredStopAtLevel=1 on machines with many cores

[Vladimir Kozlov]

On Tue, 11 Jan 2022 08:27:49 GMT, Hao Sun <haosun at openjdk.org> wrote:

> This test failure occurred on machines with a lot of cores. Here is a
> snippet from the log file:
> 
> 
> ----------System.out:(14/1085)----------
> CompileCommand: dontinline compiler/codecache/stress/Helper$TestCase.method bool dontinline = true
> [0.046s][warning][codecache] CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled.
> [0.046s][warning][codecache] Try increasing the code heap size using -XX:NonProfiledCodeHeapSize=
> CodeHeap 'non-profiled nmethods': size=8Kb used=7Kb max_used=7Kb free=0Kb
>  bounds [0x0000ffff97b55000, 0x0000ffff97b57000, 0x0000ffff97b57000]
> CodeHeap 'non-nmethods': size=16376Kb used=941Kb max_used=941Kb free=15434Kb
>  bounds [0x0000ffff96b57000, 0x0000ffff96dc7000, 0x0000ffff97b55000]
>  total_blobs=269 nmethods=8 adapters=194
>  compilation: disabled (not enough contiguous free space left)
>  stopped_count=1, restarted_count=0
>  full_count=1
> Error occurred during initialization of boot layer
> java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(MemberName)Object/invokeStatic
> Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(MemberName)Object/invokeStatic
> 
> 
> On machines with many cores, the number of C1 temporary code buffers is
> big. See [1]. In my local test on a machine with 224 cores, `c1_count`
> equals to 21, and the total size for non-nmethod heap increases to about
> 16.5M.
> 
> In this test case, `ReservedCodeCacheSize` is set as 16M, which is not
> enough for the non-nmethod heap. See [2]. As a result, non-profiled heap
> is set to (twice) the minimal size. As shown in the log file, the size
> is only 8Kb, which is very small and leads to failure at initialization
> phase.
> 
> In this patch, we increase `ReservedCodeCacheSize` from 16M to 64M,
> which is big enough for machines with 1024 cores. Note that we continue
> to use the initial value for variable `largeBlobSize`.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeCache.cpp#L200
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeCache.cpp#L216

There is specific code to take into account CodeCache size when we calculate number of compiler thread:
https://github.com/openjdk/jdk18/blob/master/src/hotspot/share/compiler/compilationPolicy.cpp#L450

Can you check why it does not work?

There is also possibility that number of compiler threads increase dynamically which is guarded by `-XX:+UseDynamicNumberOfCompilerThreads` flag. Try to switch it off in this test.

You can also set small value with `-XX:CICompilerCount=n' for this test. Increasing CodeCachecsize to 64M may help your case but we can have machines with core count even larger.

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

PR: https://git.openjdk.java.net/jdk18/pull/93