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

[Doerr, Martin]

Hi Tobias,

thanks for improving. Your update looks good.

Best regards,
Martin


-----Original Message-----
From: Tobias Hartmann <tobias.hartmann at oracle.com> 
Sent: Montag, 29. Oktober 2018 13:22
To: Doerr, Martin <martin.doerr at sap.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: [12] RFR(S): 8177899: Tests fail due to code cache exhaustion on machines with many cores

Hi Martin,

On 26.10.18 16:21, Doerr, Martin wrote:
>> Well it's just an upper limit and the number of compiler threads that are actually created should be
>> controlled by -XX:+UseDynamicNumberOfCompilerThreads.
> I know, but it looks like a complicated computation for a simple task which is difficult to maintain if the other code changes.
> As you have written, it can happen that the threads really get started and I don't see any benefit of starting so many threads that most of them can never generate a nmethod because it simply wouldn't fit.
> Anyway, your change seems to fix the issue and if other reviewers like it this way, ok.

Yes I just think that since the available space in the code cache is a dynamic property, it should
also be used in a dynamic way to bound the number of compiler threads. I.e, ReservedCodeCacheSize
should serve as an upper bound for CICompilerCound and the actual available space should be part of
the UseDynamicNumberOfCompilerThreads heuristic.

>> I think the heuristic should be improved to
>> consider the available space in the code cache as well (not only the available memory). Since the
>> available space in the code cache depends on many factors, I don't think a constant is feasible. I
>> would prefer to file a RFE for that.
> That sounds like a good idea, too.

I've filed JDK-8213086 [1]. Feel free to take it, I probably won't have time to work on it soon.

>> While looking at the computation again, I've noticed that JDK-8209594 increased the buffer size.
>> I've updated C2Compiler::initial_code_buffer_size() accordingly:
>> http://cr.openjdk.java.net/~thartmann/8177899/webrev.02/
> Thanks for updating. Looks correct. I think this function could be used in compile.cpp, now to avoid code duplication.

Right, I've used the corresponding function both in c1_Compiler.cpp and c2compiler.cpp:
http://cr.openjdk.java.net/~thartmann/8177899/webrev.03/

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8213086