On Wed, Aug 24, 2016 at 6:18 PM, Jenny Zhang <[email protected]> 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.
_______________________________________________ hotspot-gc-use mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
