RFR(S): 8213086: Compiler thread creation should be bounded by available space in memory and Code Cache

[Tobias Hartmann]

Hi Martin,

this looks good to me too. Thanks for fixing!

Best regards,
Tobias

On 30.10.18 12:46, Doerr, Martin wrote:
> Hi Vladimir,
> 
> added comment in place: "If SegmentedCodeCache is off, both values refer to the single heap (with type CodeBlobType::All)."
> 
> I have run some tests with -XX:+TraceCompilerThreads -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler
> and also with -XX:-SegmentedCodeCache and all seems to work fine.
> 
> Waiting for a 2nd review.
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
> Sent: Montag, 29. Oktober 2018 19:27
> To: Doerr, Martin <martin.doerr at sap.com>; Tobias Hartmann (tobias.hartmann at oracle.com) <tobias.hartmann at oracle.com>
> Cc: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8213086: Compiler thread creation should be bounded by available space in memory and Code Cache
> 
> On 10/29/18 10:13 AM, Doerr, Martin wrote:
>> Hi Vladimir,
>>
>> thank you for reviewing so quickly.
>>
>> unallocated_capacity() doesn't return 0. If SegmentedCodeCache is off, the code cache gets initialized for CodeBlobType::All (codeCache.cpp:1088). Given that, CodeHeap::accepts always returns true (heap.hpp:203) and CodeCache::get_code_heap returns the single heap correctly.
> 
> Good. Add comment to avoid confusion.
> 
>>
>> But I'm not sure about AOT. Do you know if using CodeCache::unallocated_capacity(CodeBlobType::MethodNonProfiled) is ok if Graal is used?
> 
> Normal CodeCache will be present in all cases regardless if Graal or AOT are used.
> 
> AOT library code segments have CodeBlobType::AOT type:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/3152b928769d/src/hotspot/share/aot/aotCodeHeap.cpp#l235
> 
> So it will not affect your code.
> 
> Thanks,
> Vladimir
> 
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: Montag, 29. Oktober 2018 17:48
>> To: Doerr, Martin <martin.doerr at sap.com>; Tobias Hartmann (tobias.hartmann at oracle.com) <tobias.hartmann at oracle.com>
>> Cc: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
>> Subject: Re: RFR(S): 8213086: Compiler thread creation should be bounded by available space in memory and Code Cache
>>
>> So the issue was / 200*M vs correct / (200*M). Thank you for finding and fixing this.
>>
>> About taking into account sizes of segmented CodeCache. If segmentation is off (-XX:-SegmentedCodeCache)
>> unallocated_capacity() will return 0:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/e53af5fa0dae/src/hotspot/share/code/codeCache.cpp#l1003
>>
>> You need to take that into account.
>>
>> Thanks,
>> Vladimir
>>
>> On 10/29/18 9:26 AM, Doerr, Martin wrote:
>>> Hi Tobias,
>>>
>>> thank you for filing https://bugs.openjdk.java.net/browse/JDK-8213086
>>>
>>> I have changed the description because the available memory doesn't get respected due to missing braces. So I'd like to
>>> fix this in addition.
>>>
>>> My test machines have too much memory to hit this case. Maybe I should try to use a docker container for testing.
>>>
>>> My initial proposal allows up to one compiler thread per 128kB of free code cache. I remember that Oracle wants to have
>>> many threads (for some SPARC scenarios) so I have chosen a small size.
>>>
>>> I'm currently ignoring that C1 also creates some small non-profiled nmethods.
>>>
>>> Please review:
>>>
>>> http://cr.openjdk.java.net/~mdoerr/8213086_compiler_limit/webrev.00/
>>>
>>> Best regards,
>>>
>>> Martin
>>>