G1gc compaction algorithm

[Martin Makundi]

BTW: We have 16 cores and we probably need 4 for serving web users, is
there a way we can utilize more efficiently the excess resources towards gc
while keeping user experienced pause at minimum?


2014-07-17 22:21 GMT+03:00 Martin Makundi <
martin.makundi at koodaripalvelut.com>:

>
>  There are 3 factors: MaxGCPauseMilli, MixedGCCountTarget,
>> G1OldCSetRegionThresholdPercent
>>
>> The candidate regions is calculated by some algorithm.
>> minimum regions = (candidate regions)/MixedGCCountTarget
>> maximum regions = (heap regions)* G1OldCSetRegionThresholdPercent
>>
>
>> If the estimated mixed gc time is < MaxGCPauseMilli, g1 will try to add
>> the candidate regions to cset while keeping the estimated time below
>> MaxGCPauseMilli, as long as it is less than maximum regions, and
>> reclaimable percentage higher than the waste limit.
>> If the estimated mixed gc time is > MaxGCPauseMilli, g1 will add minimum
>> regions to cset.
>>
>
> What's the science behind these equations (in short) or are they purely
> ad-hoc?
>
> **
> Martin
>
>
>
>>
>> In your case, MaxGCPauseMilli is low and MixedGCCountTarget is 80.  So it
>> can only add 2 when the estimated time >  MaxGCPauseMilli
>>
>> Thanks,
>> Jenny
>>
>> On 7/16/2014 9:14 PM, Martin Makundi wrote:
>>
>>  >  This is a diagnostic parameter, you need to apply with
>> > -XX:+UnlockDiagnosticVMOptions -XX:+G1PrintRegionLivenessInfo
>>
>>  Thanks, will try that.
>>
>>  It will first add old regions if the estimated time is under the
>>> MaxGCPauseMilli.  If the estimated time is higher than  MaxGCPauseMilli, it
>>> will add the minimum decided by #candidate-regions/MixedGCCountTarget.  If
>>> you set MixedGCCountTarget too high, the minimum will be too low.  In your
>>> case, it is 2.
>>>
>>
>>  Hmm.. what is the logic behind this
>> candidate-regions/MixedGCCountTarget? Is there no way to tell the gc to
>> estimate the max number of regions it could maybe achieve in the time
>> available and do that instead of 2?
>>
>>  **
>> Martin
>>
>>>  Thanks,
>>> Jenny
>>>
>>>  On 7/16/2014 6:46 PM, Martin Makundi wrote:
>>>
>>>  2. For most of the time, eden size is 1.4g, survivor 150m, the rest is
>>>> old gen.  I am not sure how much of the old gen is used for humongous
>>>> allocations.  But it seems there are some tunings you can try to help mixed
>>>> gc:
>>>>   - old regions added to cset is 2-14 for mixed gc.  Most of the time
>>>> the reason is 'predicted time too high'.  You can try either increase
>>>> -XX:MaxGCPauseMillis to a higher value, or decrease
>>>> -XX:G1MixedGCCountTarget (currently it is 80) so that more old regions can
>>>> be added.
>>>>
>>>
>>>  Does it attempt to do any mixed gc if it cannot do
>>> all G1MixedGCCountTarget or is the value G1MixedGCCountTarget just an upper
>>> limit? If it just is an upper limit we could keep it at 80 or higher?
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140719/6b64a29b/attachment.html>