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

[Doerr, Martin]

Hi Tobias,

thanks for the review.

I think I should request a 11u backport after it was tested in jdk12 for some time.

Best regards,
Martin


-----Original Message-----
From: Tobias Hartmann <tobias.hartmann at oracle.com> 
Sent: Dienstag, 30. Oktober 2018 12:50
To: Doerr, Martin <martin.doerr at sap.com>; Vladimir Kozlov <vladimir.kozlov 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

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