RFR: 8222182: ZGC: Use SoftMaxHeapSize to guide GC heuristics

Per Liden per.liden at oracle.com
Thu Apr 11 11:50:07 UTC 2019


Hi Thomas,

Thank for looking at the patch. However, I'm afraid your comments are 
based on incorrect assumptions, which makes them difficult to address. 
I'll try to clarify a few key points below. Hope that helps.

On 4/11/19 12:44 PM, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2019-04-11 at 12:30 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2019-04-10 at 19:23 +0200, Per Liden wrote:
>>> The ZDriector currently uses max heap size (-Xmx) as input when
>>> deciding
>>> on when to start a GC cycle. We should start using SoftMaxHeapSize
>>> instead. Of course, this change depends on JDK-8222145 "Add
>>> -XX:SoftMaxHeapSize flag", which is currently out for review.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222182
>>> Webrev: http://cr.openjdk.java.net/~pliden/8222182/webrev.0
>>
>>    to be able to review this, what is the expected reaction (and
>> limitations) of the collector on this, particularly in unusual cases,
>> like what should happen if an allocation request goes over the soft
>> limit?
>>
>>  From what I understand, allocation of ZPages will fail as normal, and
>> an allocation stall will occur as normal. This does not sound like a
>> "soft" max heap size.

An allocation would never fail in this case. The allocation path has no 
interaction with SoftMaxHeapSize. SoftMaxHeapSize only serves as input 
to the heuristics in ZDirector, nothing else.

>>
>> Which also means that there is opportunity for some allocating Java
>> threads not having recognized the new value of SoftMaxHeapSize as it
>> is read without synchronization - so some allocations will go beyond
>> that soft limit, while others may fail (and seem to cause an
>> allocation stall).
>>
>> Neither the flag CSR nor the CR talks about this.
>>
> 
> The code in ZPageAllocator::max_available() is especially fishy: if
> current_max_capacity() is smaller than used (that value can be set to
> anything between -Xms and -Xmx), then the result of the available
> calculation overflows and seems to result in no action until used()
> gets down below SoftMaxHeapSize.

current_max_capacity() is never smaller than used, by definition. Note 
that current_max_capacity() is the internal hard upper limit, and is 
unrelated to SoftMaxHeapSize.

> 
> I would expect that the collector starts a GC cycle to hopefully get
> used() down to this new SoftMaxHeapSize.
> 
> Also, after the user setting the new value, how long would it take for
> the collector to recognize the new value? Is it possible that it never

An updated SoftMaxHeapSize will be detected within 100ms (which is the 
current ZDirector interval).

cheers,
Per

> acts on it (i.e. no Zpage allocation at all)? It would really be
> interesting to document this to set the expectations for the user.
> Afaik there is a regularly scheduled gc cycle in ZGC based on mutator
> activity, but that may take how long?
> 
> Please document expected behavior depending on current state (at least
> heap usage) when various values are set by the user. Otherwise there is
> no way to determine whether ZGC is working correctly.
> 
> Or maybe point out a location on the wiki where this is documented.
> 
> That change would also _at least_ be worth a release note imho to get
> at least some recognition (if not a JEP ;))
> 
>> What testing has been done for this? There is no test.
> 
> Thanks,
>    Thomas
> 
> 



More information about the hotspot-gc-dev mailing list