G1gc compaction algorithm

Martin Makundi martin.makundi at koodaripalvelut.com
Wed Jul 23 15:01:16 UTC 2014


1. Log says "recent GC overhead higher than threshold after GC, recent GC
overhead: 13.94 %, threshold: 10.00 %" what is that 10% threshold how can
it be changed and what will it affect?

2. Today I changed -XX:G1HeapWastePercent=0 and didn't get any Full GC:s. I
assume this is needed to keep heap clean for those random humongous
allocations...

**
Martin


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

> Hi!
>
> Here is the most recent attempt, we increased GCPauseIntervalMillis to
> 10000 so that 10% will be a longer time for doing mixed sets. However, we
> still seem to get a Full GC at "[Full GC 20G->17G(30G), 60.0458620 secs]"
> due to humongous allocations.
>
> Any suggestions how to mitigate the Full GC? Here is the full log with
> parameters:
>
> http://81.22.250.165/log
>
> **
> Martin
>
>
> 2014-07-19 5:38 GMT+03:00 Martin Makundi <
> martin.makundi at koodaripalvelut.com>:
>
> 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/20140723/eda532d6/attachment.html>


More information about the hotspot-gc-use mailing list