JDK-6819061 : G1: eliminate serial Other times that are proportional to the collection set length
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14,hs15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-03-18
  • Updated: 2013-09-18
  • Resolved: 2010-05-05
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 6 JDK 7 Other
6u21pFixed 7Fixed hs18Fixed
Related Reports
Relates :  
JDK-6868854 - G1: Eliminate serial Other times at the end of a GC pause
Relates :  
JDK-6819085 - G1: use larger and/or user settable region size
Description
We recently tried G1 on a 32GB heap, with a 4GB / 8GB young gen. The serial Other time was very high, around 50ms for the 4GB and 100ms for the 8GB young gen, which looks proportional to the collection set (i.e., the young gen in this case). This is because we do work proportional to the collection set before and after the parallel part of the collection (we add regions to the collection set before and we free them after). We should eliminate such  expensive serial bottleneck from the code.
We're going to split this CR into two: this one and CR 6868854. This one is going to deal with high serial Other times at the beginning of a GC pause. CR 6868854 is going to deal with high serial Other times at the end of a GC pause.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1316cec51b4d
22-04-2010
EVALUATION We reran the application mentioned in the Description with an instrumented JVM to see where the Other time is going. I timed the Other time before and after the main body of the collection. Here's where the time is going (1MB regions, 8GB young gen): All of it is 100ms: [Other: 100.2 ms] The "before" Other time is just under 21ms: [Pre Other: 20.78 ms] and most of it is going to the collection set choice: [CSet Choice: 20.48 ms] The "after" Other time is almost 82ms: [Post Other: 81.88 ms] and most of it is the freeing of the collection set: [CSet Free: 80.80 ms] as well as the recording of the pause at the policy (where the updated the pause stats): [Post Record: 1.07 ms] We also did a quick experiment to see the Other time is affected by the region size. Here are the above stats with 8MB regions (see also 6819085). [Other: 10.4 ms] [Pre Other: 2.43 ms] [CSet Choice: 2.25 ms] [Post Other: 7.52 ms] [CSet Free: 6.48 ms] [Post Record: 1.04 ms] The young gen was the same size (8GB), so this should mean that the collection set had 8 times fewer regions. Note, however, that the CSet choice and freeing times (which again mostly dominate the Other time) are much shorter than 1/8th the time for 1MB regions. So, maybe there's an extra pathology there. Having said that, we should remove any operations that are proportional to the heap / collection set size from the serial phase of the collection.
27-03-2009