[12] RFR(S): 8177899: Tests fail due to code cache exhaustion on machines with many cores

[Vladimir Kozlov]

I am thinking about Igor's comment in the bug report:

"The easy fix would be to add -XX:CICompilerCount=2 to the affected tests. but we might also want to think about 
changing the default value of CICompilerCount to take code cache size into consideration and not just number of cpus."

Even with UseDynamicNumberOfCompilerThreads it is possible to use all CICompilerCount compiler threads when there are a 
lot of request. And code respect this number.

I think scaling down CICompilerCount based on CodeCache size is preferable. Unless CICompilerCount is specified on 
command line - in which case we should issue a error as we do now but more verbose including CICompilerCount.

Thanks,
Vladimir

On 10/22/18 3:19 AM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8177899
> http://cr.openjdk.java.net/~thartmann/8177899/webrev.00/
> 
> On machines with many cores/CPUs, we hit the "Not enough space in non-nmethod code heap to run VM"
> check when running with -XX:+SegmentedCodeCache and a small code heap size because we assume that
> all space in the non-nmethod code heap will be occupied by temporary code buffers. This is too
> conservative for two reasons:
> 1) With -XX:+UseDynamicNumberOfCompilerThreads (default since JDK-8198756), we create compiler
> threads on demand and might not even get close to creating as many threads as initially assumed.
> 2) The required space also depends on dynamic properties like the number of i2c/c2i adapters and we
> will gracefully handle the OOM case by throwing an error anyway.
> 
> I've removed the check and verified that all affected tests pass. Of course, one can still trigger a
> "no space to run compilers" warning or a "VirtualMachineError: Out of space in CodeCache for method
> handle intrinsic" by running with something like -XX:CICompilerCount=50 -XX:ReservedCodeCacheSize=3M
> -XX:-UseDynamicNumberOfCompilerThreads but that's a user error (or test bug).
> 
> Thanks,
> Tobias
>