Odd G1GC behavior on 8u91

[Vitaly Davidovich]

On Wed, Aug 24, 2016 at 6:18 PM, Jenny Zhang <yu.zhang at oracle.com> wrote:

> More comments about the questions
>
> Thanks
> Jenny
>
> On 8/24/2016 11:43 AM, Vitaly Davidovich wrote:
>
>> Right before the Full GC, ergonomics report a failure to expand the heap
>> due to an allocation request of 32 bytes.  Is this implying that a mutator
>> tried to allocate 32 bytes but couldn't? How do I reconcile that with
>> Eden+Survivor occupancy reported right above that?
>>
> Yes, it means the mutator tries to allocate 32byte but can not get it.
> Heap won't expand as it already reaches max heap.
>
> Do you see any humongous objects allocatoin?

As mentioned in my previous email, I don't see any humongous allocations
recorded.  The Humongous Register/Reclaim output does show non-zero timing,
so not sure if the log is simply missing them or something else is going on.

>
>
>> Young gen is sized to 30GB, total heap is 96GB.  Allocation rate of the
>> application is roughly 1GB/s.  Am I correct in assuming that allocation is
>> outpacing concurrent marking, based on the above? What tunable(s) would you
>> advise to tweak to get G1 to keep up with the allocation rate? I'm ok
>> taking some throughput hit to mitigate 90s+ pauses.
>>
>> The entire log might give a better picture. Especially if the marking
> cycle is triggered, how well the mixed gc cleans up the heap.
>
> Are there particular gc lines you're looking for? I can grep for them
quickly and provide that for you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20160824/1ad3a5a8/attachment.html>