Hi Thomas, Thanks for your kind interpretation. The whole GC log is available at https://github.com/JerryLead/Misc/blob/master/AllocatedLargerThanUsage-G1/stdout-E18 .
This wrong size problem affects our GC performance analysis. Maybe we can enhance the G1 log mechanism to let it output the precise usage/allocated sizes of eden, humongous, and old generation in the future releases. Thanks, Lijie On Fri, Apr 13, 2018 at 3:35 PM, Thomas Schatzl <thomas.scha...@oracle.com> wrote: > Hi, > > On Fri, 2018-04-13 at 10:49 +0800, Lijie Xu wrote: > > Hi all, > > > > I currently found a "allocated < usage" problem in the G1 log as > > follows. > > > > [Eden: 342.0M(3296.0M)->0.0B(3890.0M) Survivors: 1024.0K->1024.0K > > Heap: 5541.2M(6655.0M)->1886.0M(6655.0M)] > > [Times: user=0.03 sys=0.00, real=0.02 secs] > > > > This log reveals that > > (1) The allocated space of "Old+Humongous" is (5541.2 - 342) = > > 5199.2MB before GC. > > (2) The usage of "Old+Humongous" is (6655 - 3296)=3359MB before GC. > > (3) The usage of "Old+Humongous" > the allocated space of > > "Old+Humongous" (Wrong) > > > > There may be a bug in the GC statistics profiler. > > due to fragmentation (holes) within the heap where G1 can not > allocate into, the usage (inverse of the space G1 can actually allocate > into) can be higher than what is actually allocated (i.e. live > objects). > > This may also explain the premature garbage collection, i.e. where Eden > is much smaller than expected before GC (there are other reasons, > including bugs, but without more detailed log output you can't tell). > > A frequent cause for this can be humongous objects. Consider increasing > heap region size in this case (it seems to be 2M on your heap right > now), to 4M or even 8M. Use -XX:G1HeapRegionSize=xx to do this. > > Thanks, > Thomas > >
_______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
