G1 eden resizing behaviour ?

charlie hunt charlie.hunt at oracle.com
Wed Dec 10 16:04:41 UTC 2014


Adding -XX:+PrintReferenceGC may also help identify which type of Reference objects are the culprit.  If it is SoftReferences (my favorite :-] ), there is some additional tweaking you can do.

Adding -XX:+ParallelRefProcEnabled, as Jenny suggested, should help shorten the length of time.

hths,

charlie

> On Dec 9, 2014, at 10:18 PM, Yu Zhang <yu.zhang at oracle.com> wrote:
> 
> Simone,
> 
> Please see my comments in line.
> 
> Thanks,
> Jenny
> 
> On 12/9/2014 6:26 AM, Simone Bordet wrote:
>> Hi,
>> 
>> On Tue, Dec 9, 2014 at 3:06 PM, Thomas Schatzl
>> <thomas.schatzl at oracle.com> wrote:
>>> This may be because the heap is already very full (around
>>> 100-G1ReservePercent) so it cuts down on the young gen size.
>>> 
>>> G1 tries to keep G1ReservePercent of heap empty to avoid evacuation
>>> failure.
>> It's not my case: I have a 32 GiB heap with a permanent live set of
>> about 5-6 GiB, so I should have plenty of space even with a 15 GiB or
>> so eden, which is what I typically see as max eden size.
> Can you add -XX:+PrintAdaptiveSizePolicy and share your logs?  I was guessing the same, that the heap is full.  The mixed gc might not clean all the garbage.  Even though the live data set is 5-6 GB, the heap can still be close to full.
>> 
>>> Another reason could be that G1 thinks that the pauses caused by marking
>>> cut too much into the available time budget (depending on your
>>> settings), so it decreases the heap.
>> You mean by the remark, which is STW ?
>> Indeed I have very long remark pauses (up to 2.5s), apparently caused
>> by weak reference processing.
>> 
>> I need to investigate this issue, as the application itself does not
>> use them (perhaps some library ?).
>> There is a big difference between the references processed in the
>> remark phase (3 millions) and those processed during a young GC (less
>> than a thousand).
>> 
>> Am I correct assuming that those processed during remark only belong
>> to tenured ?
> I agree.  Do you have -XX:+ParallelRefProcEnabled?  This will help reducing the refproc time, but 3 millions is a lot.
>> 
>> Thanks !
>> 
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use



More information about the hotspot-gc-use mailing list