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

[Tobias Hartmann]

Thanks Vladimir.

Best regards,
Tobias

On 29.10.18 17:53, Vladimir Kozlov wrote:
> Yes, looks good.
> 
> Thanks,
> Vladimir
> 
> On 10/29/18 6:54 AM, Tobias Hartmann wrote:
>> Hi Martin,
>>
>> thanks for the review!
>>
>> Vladimir, are you okay with that version as well?
>>
>> Best regards,
>> Tobias
>>
>> On 29.10.18 14:32, Doerr, Martin wrote:
>>> 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
>>>