JDK-6484965 : G1: piggy-back liveness accounting phase on marking
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-10-23
  • Updated: 2013-10-04
  • 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 :  
Currently, the parallel marking phase in G1 only marks objects on
their bitmap and not sum up the amount of live bytes per region. This
is done serially in a subsequent phase after remark and before
cleanup. This serial iteration over the heap turns out to be a
performance bottleneck on medium to large MPs, when the application
live size is non-trivial. This accounting phase should be

EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d30fa85f9994

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d30fa85f9994

EVALUATION Given that this is an RFE I'm going to go ahead and retarget this to hs23.

EVALUATION Non-trivial change we never quite got done on time given that we concentrated on more important ones (ref processing during GCs, reliability fixes, etc.). We'd like to defer it to hs23.

EVALUATION See Comments.

SUGGESTED FIX There are a couple of ways to achieving this. The first one is to simply parallelize the accounting phase and still execute it between remark and cleanup. The second one is to scrap the separate accounting phase and piggy-back it on the marking phase (use a data structure local to each GC thread to account for all the objects that GC thread marked and sum up the thread-local data structure in the end). I favor the latter, as I've always thought the whole point of G1 is to avoid heap sweeps.