Minor question about logging

Thomas Schatzl thomas.schatzl at oracle.com
Mon Mar 9 10:32:43 UTC 2020


Hi,

On 08.03.20 06:01, Eugeniu Rabii wrote:
> Hello,
> 
> I have a very simple program that constantly allocates some byte arrays 
> (of 2 MB) each (running with the latest jdk-13). I run it with :
> 
> -Xms20M
> -Xmx20M
> -Xmn10M
> "-Xlog:heap*=debug" "-Xlog:gc*=debug" "-Xlog:ergo*=debug"
> 
> 
> For example:
> 
>      public static void main(String[] args) {
[...]
>      }
> 
> In logs, I see something that is puzzling me:
> 
> 
> [0.066s][debug][gc,ergo       ] Request concurrent cycle initiation 
> (requested by GC cause). GC cause: G1 Humongous Allocation
> [0.066s][debug][gc,heap       ] GC(0) Heap before GC invocations=0 (full 
> 0): garbage-first heap   total 20480K, used 6908K [0x00000007fec00000, 
> 0x0000000800000000)
> [0.066s][debug][gc,heap       ] GC(0)   region size 1024K, 1 young 
> (1024K), 0 survivors (0K)
> 
> OK, so Heap Before: 1 young, 0 survivors.
> 
> Then:
> 
> [0.071s][info ][gc,heap        ] GC(0) Eden regions: 1->0(9)
> [0.071s][info ][gc,heap        ] GC(0) Survivor regions: 0->1(2)
> [0.071s][info ][gc,heap        ] GC(0) Old regions: 0->0
> 
> So the next cycle will have 9 Eden Regions and 2 Survivor ones (at least 
> this is how I read the source code of where this is logged)

The nine eden regions are estimates based on pause time and some factors 
like estimated allocation rate. The two survivor ones are actually 
survivor regions allowed in the current GC (allowed survivor region 
length is always determined at the start of GC). It should probably read

Survivor regions: 0(2)->1

In this case the limit for entire young gen is G1MaxNewSizePercent, 
which by default is 60%; 60% of 20M is 12M, which is distributed across 
Survivor and Eden according to SurvivorRatio (=8).

> 
> Then a GC(1) concurrent cycle happens:
> 
> [0.071s][info ][gc             ] GC(1) Concurrent Cycle
> 
> And the next cycle is where I fail to understand the logging:
> 
> [0.076s][debug][gc,heap           ] GC(2) Heap before GC invocations=2 
> (full 0): garbage-first heap   total 20480K, used 7148K 
> [0x00000007fec00000, 0x0000000800000000)
> [0.076s][debug][gc,heap           ] GC(2)   region size 1024K, 2 young 
> (2048K), 1 survivors (1024K)
> 
> How come 2 young, 1 survivors? When the previous cycle said 9 Eden, 2 
> Survivor.

Humongous allocations can make initial estimations about young gen size 
obsolete.

I.e. the humongous allocations (directly into old gen) made old gen 
occupancy cross the current threshold to start old gen reclamation. 
Otherwise the humongous objects would have filled up the entire heap, 
causing full gc.

Thanks,
   Thomas


More information about the hotspot-gc-use mailing list