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

Per Liden per.liden at oracle.com
Tue May 21 13:48:43 UTC 2019


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