Review request: 8022880: False sharing between PSPromotionManager instances

[Stefan Karlsson]

http://cr.openjdk.java.net/~stefank/8022880/webrev.00/

We've seen a couple of instances of false sharing when accessing fields 
from the beginning and the end of the PSPromotionManager instances. This 
both decreases the performance of the Parallel Scavenge young GC and 
makes it hard to do reliable GC benchmarks on bigger machines.

This was first seen in:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196911 : command 
line length affects performance

The patch makes sure that each PSPromotionManager starts at a 
cache-line-aligned address and is padded to have a cache-line-aligned size.

It doesn't use the exiting Padded<T> class, since it (unnecessarily) 
wastes too much memory, but instead introduces a PaddedEnd<T> class. 
This class only pads enough to get the cache-line-aligned size and it's 
up to the user to align the start of the instance. This works well in 
this specific case, where all the PSPromotionManagers are together in an 
Array. A PaddedArray<T> class was added to hide the memory layout code.

Testing:

1) JPRT

2) SPECjbb2005 - 2 socket, 8 core, HT machine on JDK8-b57 + recent 
HotSpot + the patch

Flags:
-showversion -Xmx29g -Xms29g -Xmn27g -XX:SurvivorRatio=60 
-XX:TargetSurvivorRatio=90 -XX:ParallelGCThreads=16 
-XX:AllocatePrefetchDistance=256 -XX:AllocatePrefetchLines=4 
-XX:LoopUnrollLimit=45 -XX:InitialTenuringThreshold=12 
-XX:MaxTenuringThreshold=15 -XX:InlineSmallCode=4300 
-XX:MaxInlineSize=270 -XX:FreqInlineSize=2700 -XX:+AggressiveOpts 
-XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy -XX:+PrintGC

Young GC times without cache aligned PSPromotionManager (ms):
36.1608
36.0164
36.3001
36.0763
36.2086
35.8151

with cache aligned PSPromotionManager:
26.2168
26.9931
27.3672
26.5155
26.0182
26.8202

Extra thanks goes to Claes Redestad for helping out with performance 
analysis and implementation-detail discussions.

thanks,
StefanK