RFR: 8224185: ZGC: Introduce "High Usage" rule

[Erik Österlund]

Hi Per and Thomas,

Looks good to me. I also would not like to see a JVM flag for this. We 
have a quite high bar before we introduce new JVM flags, to avoid JVM 
flag hell. Especially for policies that are likely to change as the 
algorithm evolves, such that the flag might become useless. And this did 
not seem to warrant a flag yet.

Thanks,
/Erik

On 2019-05-20 11:44, Per Liden wrote:
> Hi Thomas,
>
> On 5/20/19 11:34 AM, Thomas Schatzl wrote:
>> Hi Per,
>>
>> On Mon, 2019-05-20 at 10:11 +0200, Per Liden wrote:
>>> Start a GC cycle if the amount of free memory is 5% or less. This is
>>> a preventive measure in the case where the application has a very
>>> low allocation rate, such that the allocation rate rule doesn't
>>> trigger, but the amount of free memory is still slowly but surely
>>> heading towards zero. In this situation, we should start a GC cycle
>>> to avoid a potential allocation stall later.
>>>
>>> Testing: New jtreg test added. Currently running tier 1-6.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224185
>>> Webrev: http://cr.openjdk.java.net/~pliden/8224185/webrev.0
>>>
>>
>>    just pointing out the obvious: this means that ZGC will potentially
>> never use 5-Epsilon% of the heap.
>>
>> I do not recommend such a threshold being a fixed, compiled in constant
>> size: while I understand that you want to have as few options as
>> possible with ZGC, 5% of 100GB are still 5GB which may be better used
>> for use in the application in some cases.
>>
>> I.e. G1 has a similar (10%) threshold, and we've run in a few
>> situations where this has been too much and unneeded, particularly with
>> large heaps.
>> Now I know that ZGC pauses are by far less intrusive than G1's, but
>> still the concurrent marking has its cost. Making it configurable would
>> allow people getting the last bit of performance out of it if they
>> want.
>
> The situation is slightly different for ZGC. This rule typically kicks 
> in when the allocation rate is very low. If the allocation rate is 
> very high, we typically collect a lot earlier than 95% full heap anyway.
>
> Regarding a flag. We've discussed this within the team, and decided to 
> not have one for now. It can be added later if it turns out to be a 
> need for it.
>
> cheers,
> Per