JDK-7127706 : G1: re-enable survivors during the initial-mark pause
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-06
  • Updated: 2013-09-18
  • Resolved: 2012-03-24
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.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-6888336 - G1: avoid explicitly marking and pushing objects in survivor spaces
Description
The changes for 6888336 (G1: avoid explicitly marking and pushing objects in survivor spaces) simplify the interaction between evacuation pauses and concurrent marking and improve the performance of evacuation pauses during concurrent marking cycles. They do so at the expense of turning off survivors during initial-mark pauses (i.e., all survivors are tenured during those pauses).

We should re-eanble survivors during initial-mark pauses.
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/eff609af17d7
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eff609af17d7
26-01-2012
PUBLIC COMMENTS We could scan the survivors as we're copying them, however this will require more work during the initial-mark GCs (and in particular: special-case code in the fast path). A better approach is to let the concurrent marking threads scan the survivors and mark everything reachable from them a) before any more concurrent marking work is done (so that we can just mark the objects, without needing to push them on a stack, and let the "finger" algorithm discover them) and b) before the next GC starts (since, if we copy them, we won't know which of the new survivors are the ones we need to scan). This approach has the advantage that it does not require any extra work during the initial-mark GCs and all the work is done by the concurrent marking threads. However, it has the disadvantage that the survivor scanning might hold up the next GC. In most cases this should not be an issue as GCs take place at a reasonably low rate. If it does become a problem we could consider the following: - like when the GC locker is active, try to extend the eden to give a bit more time to the marking threads to finish scanning the survivors - instead of waiting for the marking threads, a GC can take over and finish up scanning the remaining survivors (typically, we have more GC threads than marking threads, so the overhead will be reduced) - if we supported region pinning, we could pin all the regions that were not scanned by the time the GC started so that the marking threads can resume scanning them after the GC completes But, let's do the simple implementation as a first cut.
17-01-2012