United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6865703 G1: parallelize cache clean up
JDK-6865703 : G1: parallelize cache clean up

Details
Type:
Enhancement
Submit Date:
2009-07-28
Status:
Closed
Updated Date:
2010-04-06
Project Name:
JDK
Resolved Date:
2010-01-15
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs16
Fixed Versions:
hs16 (b08)

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

Description
When running performance tests with large heaps (24G or so) I noticed that GC worker 0 was taking longer in the RS updating phase than the rest. Here's an example:

      [Update RS (ms):  4.6  2.3  2.4  2.6  2.3  2.4  2.5  2.7  2.2  2.6  2.6  2.4  2.3
       Avg:   2.6, Min:   2.2, Max:   4.6]

When the pause times were short, this resulted in long termination times for all but worker 0:

      [Termination (ms):  0.0  2.0  1.9  1.9  2.0  1.9  1.9  1.9  1.9  1.9  2.0  1.9  1.9
       Avg:   1.8, Min:   0.0, Max:   2.0]

which added unnecessary time to the collection pause.

                                    

Comments
SUGGESTED FIX

The fix is to parallelize the card cache cleaning code (by, say, chunking the cache and each worker having to claim each chunk before processing it).
                                     
2009-07-28
EVALUATION

The bottleneck is the worker 0 alone serially cleans up the card cache. And if that processing takes a non-trivial amount of time, then the rest might have to wait for it during termination.
                                     
2009-07-28
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/15c5903cf9e1
                                     
2009-08-04
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15c5903cf9e1
                                     
2009-08-06



Hardware and Software, Engineered to Work Together