Java Reference
In-Depth Information
[Eden: 0.0B(400.0M)->0.0B(400.0M)
Survivors: 0.0B->0.0B Heap: 2006.4M(2048.0M)->2006.4M(2048.0M)]
[Times: user=1.70 sys=0.04, real=0.26 secs]
2226.510: [Full GC (Allocation Failure)
2227.519: [SoftReference, 4329 refs, 0.0005520 secs]
2227.520: [WeakReference, 12646 refs, 0.0010510 secs]
2227.521: [FinalReference, 7538 refs, 0.0005660 secs]
2227.521: [PhantomReference, 168 refs, 0.0000120 secs]
2227.521: [JNI Weak Reference, 0.0000020 secs]
2006M->907M(2048M), 4.1615450 secs]
[Times: user=6.76 sys=0.01, real=4.16 secs]
This failure means the mixed collections need to happen more quickly; each young col-
lection needs to process more regions in the old generation.
Evacuation failure
When performing a young collection, there isn't enough room in the survivor spaces and
the old generation to hold all the surviving objects. This appears in the GC logs as a spe-
cific kind of young GC:
60.238: [GC pause (young) (to-space overflow), 0.41546900 secs]
This is an indication that the heap is largely full or fragmented. G1 will attempt to com-
pensate for this, but you can expect this to end badly: G1 will resort to performing a full
GC. The easy way to overcome this is to increase the heap size, though some possible
solutions are given in Advanced Tunings .
Humongous allocation failure
Applications that allocate very large objects can trigger another kind of full GC in G1;
see G1 allocation of humongous objects . There are no tools to diagnose that situation
specifically from the standard GC log, though if a full GC occurs for no apparent reason,
it is likely due to an issue with humongous allocations.
Search WWH ::




Custom Search