United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7127706 G1: re-enable survivors during the initial-mark pause
JDK-7127706 : G1: re-enable survivors during the initial-mark pause

Details
Type:
Enhancement
Submit Date:
2012-01-06
Status:
Closed
Updated Date:
2012-03-24
Project Name:
JDK
Resolved Date:
2012-03-24
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs23
Fixed Versions:
hs23 (b12)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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
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.
                                     
2012-01-17
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eff609af17d7
                                     
2012-01-26
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/eff609af17d7
                                     
2012-03-22



Hardware and Software, Engineered to Work Together