Impressive. Sounds like the stride size should be ergonomically set based on heap size & #workers, rather than being a static value? If the optimal varies slowly (i.e. is not sensitive above a specific value, such as your 4K), perhaps that should be the default for now, with suitable ergonomic downsizing for smaller heap sizes , if needed.<br>
<br>Copying gc-dev, requesting filing a CR for that ergo enhancement, or at least a change in default value?<br><br>PS: BTW, Do you have the CR# for the unallocated block change, just to refresh collective memory? I would have thought that empty unallocated blocks because they would have no dirty cards would be quickly taken care of. A large regression seems a bit surprising.<br>
<br>-- ramki<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 9:58 PM, Alexey Ragozin <span dir="ltr"><<a href="mailto:alexey.ragozin@gmail.com" target="_blank">alexey.ragozin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
I have found similar regression testing young GC performance.<br>
<br>
After investigation I have come to conclusion that culprit is<br>
-XX:+BlockOffsetArrayUseUnallocatedBlock VM option (requires<br>
-XX:+UnlockDiagnosticVMOptions).<br>
<br>
This option is true is 1.6 and false in 1.7. Commit comment means some<br>
concurrency issues with that flag.<br>
<br>
But you should not blame JVM for discrepancy in your test. Problem is<br>
withing your test which is using only small fraction of 50GiB.<br>
BlockOffsetArrayUseUnallocatedBlock allows JVM exclude not-yet-used<br>
memory from collection. So in 1.6 your benchmark effectively measures<br>
heapsize of 1-4 GiB.<br>
<br>
IMHO you probably adjust your test to use more realistic memory<br>
pattern (I expect 1.7 be a bit slower, though, at least that was an<br>
outcome from my testing).<br>
<br>
If you interested in minimizing young GC time at a look at<br>
<a href="http://blog.ragozin.info/2012/03/secret-hotspot-option-improving-gc.html" target="_blank">http://blog.ragozin.info/2012/03/secret-hotspot-option-improving-gc.html</a><br>
<br>
Regards,<br>
Alexey<br>
<div><div class="h5"><br>
> We're in the process of doing some performance testing with 1.7, and we're seeing much longer ParNew times in 1.7 than we saw in 1.6. We could use some help isolating the cause.<br>
><br>
> Running an identical performance test of an hour's length, with 1.6u37 we're seeing only 0.009% of pauses over 100ms and just 0.09% over 10ms, but with 1.7u9, we're seeing 64% of pauses over 100ms.<br>
><br>
> Here is typical comparison of a ParNew between the two. It was run with -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintCommandLineFlags -XX:PrintFLSStatistics=1 -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime.<br>
><br>
> 1.6u37<br>
><br>
> 2012-11-25T16:51:13.145-0600: 1498.096: [GC Before GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 2132560492<br>
> Max Chunk Size: 2132560492<br>
> Number of Blocks: 1<br>
> Av. Block Size: 2132560492<br>
> Tree Height: 1<br>
> Before GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 512<br>
> Max Chunk Size: 512<br>
> Number of Blocks: 1<br>
> Av. Block Size: 512<br>
> Tree Height: 1<br>
> 1498.096: [ParNew<br>
> Desired survivor size 107347968 bytes, new threshold 4 (max 4)<br>
> - age 1: 614064 bytes, 614064 total<br>
> - age 2: 39344 bytes, 653408 total<br>
> - age 3: 322432 bytes, 975840 total<br>
> - age 4: 1208 bytes, 977048 total<br>
> : 1679253K->1224K(1887488K), 0.0015070 secs] 1792056K->114027K(52219136K)After GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 2132560412<br>
> Max Chunk Size: 2132560412<br>
> Number of Blocks: 1<br>
> Av. Block Size: 2132560412<br>
> Tree Height: 1<br>
> After GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 512<br>
> Max Chunk Size: 512<br>
> Number of Blocks: 1<br>
> Av. Block Size: 512<br>
> Tree Height: 1<br>
> , 0.0016110 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]<br>
> Total time for which application threads were stopped: 0.0022330 seconds<br>
><br>
> 1.7u9:<br>
><br>
> 2012-11-25T19:10:40.869-0600: 1498.458: [GC Before GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 2136954070<br>
> Max Chunk Size: 2136954070<br>
> Number of Blocks: 1<br>
> Av. Block Size: 2136954070<br>
> Tree Height: 1<br>
> Before GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 0<br>
> Max Chunk Size: 0<br>
> Number of Blocks: 0<br>
> Tree Height: 0<br>
> 1498.458: [ParNew<br>
> Desired survivor size 107347968 bytes, new threshold 6 (max 6)<br>
> - age 1: 1122960 bytes, 1122960 total<br>
> - age 2: 1560 bytes, 1124520 total<br>
> - age 3: 2232 bytes, 1126752 total<br>
> - age 4: 324760 bytes, 1451512 total<br>
> - age 5: 2232 bytes, 1453744 total<br>
> - age 6: 728 bytes, 1454472 total<br>
> : 1680121K->2393K(1887488K), 0.1132030 secs] 1759235K->81509K(52219136K)After GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 2136954070<br>
> Max Chunk Size: 2136954070<br>
> Number of Blocks: 1<br>
> Av. Block Size: 2136954070<br>
> Tree Height: 1<br>
> After GC:<br>
> Statistics for BinaryTreeDictionary:<br>
> ------------------------------------<br>
> Total Free Space: 0<br>
> Max Chunk Size: 0<br>
> Number of Blocks: 0<br>
> Tree Height: 0<br>
> , 0.1133210 secs] [Times: user=1.45 sys=0.00, real=0.11 secs]<br>
> Total time for which application threads were stopped: 0.1142450 seconds<br>
><br>
> Notice the 2ms application stop time vs 114ms. We can point you all at full GC logs<br>
><br>
> For what it's worth we repeated this test on 1.7 with our standard set of 1.6 arguments that we've had success with in the past:<br>
><br>
> -d64 -server -Xmx50g -Xms50g -XX:MaxNewSize=2g -XX:NewSize=2g -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSParallelSurvivorRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:RefDiscoveryPolicy=1 -XX:ParallelCMSThreads=3 -XX:CMSMaxAbortablePrecleanTime=3600000 -XX:CMSInitiatingOccupancyFraction=83 -XX:+UseParNewGC<br>
><br>
> as well as these minimal CMS args:<br>
><br>
> -d64 -server -Xmx50g -Xms50g -XX:MaxNewSize=2g -XX:NewSize=2g -XX:+UseConcMarkSweepGC -XX:+UseParNewGC<br>
><br>
> The results were more or less the same.<br>
><br>
> Are there some additional JVM args that we can enable to shed some light on the big discrepancy in pause times?<br>
><br>
> Thanks.<br>
</div></div>_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div><br>