<div dir="ltr">Hi Thomas,<div><br></div><div>Thanks for your kind interpretation. The whole GC log is available at <a href="https://github.com/JerryLead/Misc/blob/master/AllocatedLargerThanUsage-G1/stdout-E18">https://github.com/JerryLead/Misc/blob/master/AllocatedLargerThanUsage-G1/stdout-E18</a>.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Lijie</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 3:35 PM, Thomas Schatzl <span dir="ltr"><<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Fri, 2018-04-13 at 10:49 +0800, Lijie Xu wrote:<br>
> Hi all,<br>
> <br>
> I currently found a "allocated < usage" problem in the G1 log as<br>
> follows.<br>
> <br>
>  Â  [Eden: 342.0M(3296.0M)->0.0B(3890.0M) Survivors: 1024.0K->1024.0K<br>
> Heap: 5541.2M(6655.0M)->1886.0M(<wbr>6655.0M)]<br>
>  [Times: user=0.03 sys=0.00, real=0.02 secs] <br>
> <br>
> This log reveals that <br>
> (1) The allocated space of "Old+Humongous" is (5541.2 - 342) =<br>
> 5199.2MB before GC. <br>
> (2) The usage of "Old+Humongous" is (6655 - 3296)=3359MB before GC.<br>
> (3) The usage of "Old+Humongous" > the allocated space of<br>
> "Old+Humongous" (Wrong)<br>
> <br>
> There may be a bug in the GC statistics profiler.<br>
<br>
</span>  due to fragmentation (holes) within the heap where G1 can not<br>
allocate into, the usage (inverse of the space G1 can actually allocate<br>
into) can be higher than what is actually allocated (i.e. live<br>
objects).<br>
<br>
This may also explain the premature garbage collection, i.e. where Eden<br>
is much smaller than expected before GC (there are other reasons,<br>
including bugs, but without more detailed log output you can't tell).<br>
<br>
A frequent cause for this can be humongous objects. Consider increasing<br>
heap region size in this case (it seems to be 2M on your heap right<br>
now), to 4M or even 8M. Use -XX:G1HeapRegionSize=xx to do this.<br>
<br>
Thanks,<br>
  Thomas<br>
<br>
</blockquote></div><br></div>