From csxulijie at gmail.com Fri Apr 13 02:49:18 2018 From: csxulijie at gmail.com (Lijie Xu) Date: Fri, 13 Apr 2018 10:49:18 +0800 Subject: "Allocated < Usage" problem in G1 log Message-ID: 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. My JDK version is java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Apr 13 07:35:38 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 Apr 2018 09:35:38 +0200 Subject: "Allocated < Usage" problem in G1 log In-Reply-To: References: Message-ID: <1523604938.2360.5.camel@oracle.com> 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 From csxulijie at gmail.com Fri Apr 13 09:01:24 2018 From: csxulijie at gmail.com (Lijie Xu) Date: Fri, 13 Apr 2018 17:01:24 +0800 Subject: "Allocated < Usage" problem in G1 log In-Reply-To: <1523604938.2360.5.camel@oracle.com> References: <1523604938.2360.5.camel@oracle.com> Message-ID: 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: