JDK-8165150 : G1 sometimes performs one or more young gcs with zero sized eden after evacuation failure before issuing a full gc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-08-31
  • Updated: 2017-12-13
  • Resolved: 2017-12-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorResolved
Related Reports
Duplicate :  
JDK-8137099 - G1 needs to "upgrade" GC within the safepoint if it can't allocate during that safepoint to avoid OoME
Description
After an evacuation failure, G1 sometimes issues young-only gcs (maybe more than one) with zero sized eden (which accomplish nothing) before doing a full gc.

E.g.

2016-08-24T15:29:12.302+0000: 17776.029: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 1795162112 bytes, new threshold 2 (max 2)
 17776.029: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 0, predicted base time: 14.07 ms, remaining time: 285.93 ms, target pause time: 300.00 ms]
 17776.029: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 0 regions, survivors: 0 regions, predicted young region time: 0.00 ms]
 17776.029: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 0 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 14.07 ms, target pause time: 300.00 ms]
2016-08-24T15:29:12.305+0000: 17776.033: [SoftReference, 0 refs, 0.0012417 secs]2016-08-24T15:29:12.307+0000: 17776.034: [WeakReference, 0 refs, 0.0007101 secs]2016-08-24T15:29:12.307+0000: 17776.035: [FinalReference, 0 refs, 0.0007027 secs]2016-08-24T15:29:12.308+0000: 17776.035: [PhantomReference, 0 refs, 0 refs, 0.0013585 secs]2016-08-24T15:29:12.309+0000: 17776.037: [JNI Weak Reference, 0.0000118 secs], 0.0089758 secs]
   [Parallel Time: 3.1 ms, GC Workers: 23]

[...]

   [Eden: 0.0B(30.0G)->0.0B(30.0G) Survivors: 0.0B->0.0B Heap: 95.2G(96.0G)->95.2G(96.0G)]
 [Times: user=0.08 sys=0.00, real=0.01 secs] 
2016-08-24T15:29:12.311+0000: 17776.038: Total time for which application threads were stopped: 0.0103002 seconds, Stopping threads took: 0.0000566 seconds
 17776.039: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: allocation request failed, allocation request: 32 bytes]
 17776.039: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 33554432 bytes, attempted expansion amount: 33554432 bytes]
 17776.039: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]
2016-08-24T15:29:12.312+0000: 17776.039: [Full GC (Allocation Failure) 2016-08-24T15:29:40.727+0000: 17804.454: [SoftReference, 5504 refs, 0.0012432 secs]2016-08-24T15:29:40.728+0000: 17804.456: [WeakReference, 1964 refs, 0.0003012 secs]2016-08-24T15:29:40.728+0000: 17804.456: [FinalReference, 3270 refs, 0.0033290 secs]2016-08-24T15:29:40.732+0000: 17804.459: [PhantomReference, 0 refs, 75 refs, 0.0000257 secs]2016-08-24T15:29:40.732+0000: 17804.459: [JNI Weak Reference, 0.0000172 secs] 95G->38G(96G), 95.5305034 secs]
   [Eden: 0.0B(30.0G)->0.0B(30.0G) Survivors: 0.0B->0.0B Heap: 95.2G(96.0G)->38.9G(96.0G)], [Metaspace: 104180K->103365K(106496K)]
 [Times: user=157.02 sys=0.28, real=95.54 secs] 

See also the thread at http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2016-August/002443.html
Comments
The behavior described here is exactly what can happen if before one thread A "upgrades" its failed young gc attempt other threads manage to schedule their young gc attempts.
13-12-2017
Deferring to tbd_major. Thid behavior, although strange, causes no harm in product builds. Users will at most experience one, or a few (depending on number of threads with allocation failure), YCs when the heap is full due to evacuation failure.
13-11-2017