JDK-8022849 : Start initial mark during mixed GC if needed
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8-pool
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-08-12
  • Updated: 2019-02-11
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
tbdUnresolved
Related Reports
Relates :  
JDK-8138740 - Start initial mark right after mixed GC if needed
Description
The check for the next cycle to be an initial mark should be after we decide if this is the last mixed GC cycle. E.g.

 269.590: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 11257511936 bytes, allocation request: 0 bytes, threshold: 6442450900 bytes (50.00 %), source: end of GC]
 269.590: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 384 regions, reclaimable: 643238328 bytes (4.99 %), threshold: 5.00 %]
, 0.1005750 secs]

The algo realized that the current cycle is a mixed GC, so it decided not to initiate a concurrent marking cycle for the next collection, but then algo after that realizes that this is going to be the last mixed GC, since we are below the threshold, so we loose the initiation of a concurrent cycle and then next cycle is a pure young. By then its too late e.g. at the end of this cycle we were at:
   [Eden: 532.0M(532.0M)->0.0B(532.0M) Survivors: 80.0M->80.0M Heap: 10.9G(12.0G)->10.6G(12.0G)]

the next young brings us to -
   [Eden: 532.0M(532.0M)->0.0B(532.0M) Survivors: 80.0M->80.0M Heap: 11.1G(12.0G)->11.1G(12.0G)]

and even though we start the concurrent cycle after this, we lose the race.

The question in this CR is whether it is useful to start initial mark during mixed GC or not to prevent going out of memory.
Comments
Thomas proposed that we convert this to an RFE and move it out to the next release.
13-04-2016
Going to look at the suggested change
19-08-2013
This is just from top of my head, likely incomplete: - more extensive changes than the ones suggested (I did not have a look in detail, neither at the proposed change here, nor at changes for allowing initial mark start during mixed gc) - needs thorough testing (but the proposed change as well) o moves away from the fixed young only->conc-marking->mixed-gcs->young-only cycle + gives new liveness information earlier, i.e. fixes the issue if the concurrent marking start is timed right
14-08-2013
What are the advantages (or disadvantages) of doing that?
13-08-2013
An alternative could be to simply start concurrent marking while mixed gcs are still being done. This worked some time ago, and should still.
13-08-2013