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

[Tobias Hartmann]

Hi Vladimir,

thanks for looking at this!

On 23.10.18 18:46, Vladimir Kozlov wrote:
> "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.

Yes we can do that but it might still happen that we run out of space (see below). Here's a new
webrev that lowers the CICompilerCount if we don't have enough space in the code cache:
http://cr.openjdk.java.net/~thartmann/8177899/webrev.01/

> 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.

There are several places where code cache allocation may still fail at runtime (for example, if
classes are loaded and adapters are created). I don't think we should be more verbose there than the
usual out of code cache space message. There are other flags that can be set by the user and affect
code cache consumption as well (for example, compilation thresholds and sweeper settings). So we
would need to include all of them. Sometimes we don't even print to the command line but throw a
java.lang.VirtualMachineError ("Out of space in CodeCache for method handle intrinsic").

The check in codeCache.cpp is still too strong. Compiler thread buffers can also go into a nmethod
code heap if the non-nmethod code heap is full. We should only check if we have at least
CodeCacheMinimumUseSpace (otherwise we might crash at startup).

Thanks,
Tobias