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

[Erik Österlund]

Hi Per,

Looks good.

/Erik

On 2019-05-21 15:48, Per Liden wrote:
> Tweaked the test slightly.
>
> Diff: http://cr.openjdk.java.net/~pliden/8224185/webrev.1-diff
> Full: http://cr.openjdk.java.net/~pliden/8224185/webrev.1
>
> /Per
>
> On 5/20/19 11:59 AM, Erik Österlund wrote:
>> 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
>>