JDK-6450584 : Improve object copying order in parallel scavenge
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-07-19
  • Updated: 2010-04-04
  • Resolved: 2006-08-25
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
6 b97Fixed 7Fixed
Related Reports
Relates :  
JDK-6459077 - Revisit object array scanning in the parallel scavenge GC
Relates :  
JDK-6629335 - CMS/ParNew: Extend depth first copying to ParNew
Relates :  
JDK-6506133 - Hotspot JVM Out of Memory Error in JDK 1.6RC1 but not in JDK 1.5.0_09
Relates :  
JDK-6460014 - Tidy up task queues
Relates :  
JDK-6962589 - remove breadth first scanning code from parallel gc
Description
This change will explore an alternative object copying for objects copied from the young to the old gen in the parallel scavenge young GC (and will apply to both +UseParallelGC and +UseParallelOldGC). The different copying order will hopefully decrease cache misses for objects accessed in the old gen.
Comments
SUGGESTED FIX The code was changed to do a depth-first traversal, instead of the previous breadth-first traversal. This improved the colocation of hash table entries / keys, string objects / char arrays. I've seen a distance of 0 between hash table entries and keys over 99% of the time in jbb2005 runs. Additionally, the colocation of string objects / char arrays has considerably improved, with a distance of 0 at 100% of time for SPECjvm98 db (this is another benchmark that benefited from the change). The main change between the implementation of breadth-first and depth-first was that, in the former case, oops are pushed on the stack after the corresponding objects have been copied, whereas in the latter oop*s are pushed on the stack when those reference locations are visited. This way, a reference location can be updated when the object it points to is copied in the future. I added a flag, -XX:+/-UseDepthFirstScavengeOrder, to allow the user to revert to the breadth-first traversal order, just in case the depth-first order causes unexpected performance problems. Alacrity shows a nice improvement across the board: http://alacrity.ireland/query/enes.jsp?VersionSelector_baseline=1.6.0%7Cb92&rwver_base=%25&VersionSelector=1.6.0%7Cb92Tony_DF_Flag-060809073207-19952&rwver_build=%25&esum=Summary&pval=0.01&type_baseline=e&type_build=o
10-08-2006
EVALUATION It turns out that the breadth-first copying order used by the parallel GC was pathological in terms of object colocation. A depth-first order gives a more natural object placement in many cases.
19-07-2006