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

Per Liden per.liden at oracle.com
Wed May 22 12:59:11 UTC 2019


Thanks Erik!

/Per

On 05/21/2019 04:00 PM, Erik Österlund wrote:
> 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
>>>
> 



More information about the hotspot-gc-dev mailing list