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

[Doerr, Martin]

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.

But I'm not sure about AOT. Do you know if using CodeCache::unallocated_capacity(CodeBlobType::MethodNonProfiled) is ok if Graal is used?

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
>