RFR: JDK-8086056: ParNew: auto-tune ParGCCardsPerStrideChunk

[Tony Printezis]

Hi Jon,

Thanks for giving it a spin. Yes, we do have specjbb2013. I’m at ECOOP / CurryOn this week. I’ll try this on Monday after I get back home. Thanks again,

Tony

On July 7, 2015 at 9:10:12 PM, Jon Masamitsu (jon.masamitsu at oracle.com) wrote:

Tony,

Are you setup to run specjbb2013?  I did a run with

the PerStride changes (original patch) vs a baseline and
saw an increase in ParNew times.  I attached a plot of the
pause times.  I used

-server -Xmx30g -Xms30g -Xmn20g -XX:+UseConcMarkSweepGC -XX:+UseLargePages

This was run on a linux system with 8 cores.

From a run of specjbb2005 on the same system there is an improvement
in the ParNew times.

I'll repeat the experiment with the latest patch.   If you can try to repeat the experiment,
that would give me some confidence that it's not just me.

Thanks.

Jon


On 07/02/2015 12:39 PM, Tony Printezis wrote:
Thomas,

Latest version:

http://cr.openjdk.java.net/~tonyp/8086056/webrev.3/

See below for comments.

On July 2, 2015 at 4:43:42 AM, Thomas Schatzl (thomas.schatzl at oracle.com) wrote:

Hi Tony, 

On Wed, 2015-07-01 at 18:05 -0400, Tony Printezis wrote: 
> Latest changes, as discussed with Bengt and Thomas, 
> 
> http://cr.openjdk.java.net/~tonyp/8086056/webrev.2/ 

a few suggestions: 

- please use braces even for simple statements in if-clauses, e.g. 

parNewGeneration.cpp: 

883 if (!UseDynamicParGCStrides) return; 


I did that. But I actually added an extra verbose statement in the body of the if-statement (I thought it’d be helpful to also print the value of ParGCCardsPerStrideChunk when the dynamic calculation is off). So, I don’t have a simple return any more, but I’ll keep that in mind in the future (was it anywhere else? I didn’t immediately spot another occurrence of that).




- Comments should start with upper case: 

parNewGeneration.hpp: 

354 // automatically calculate ParGCCardsPerStrideChunk based on the 
old 


Done.




- parameter calculation in ParNewGeneration::adjust_cards_per_stride: 
- DynamicParGCStridesMinSize should be > 0 (only if ! 
UseDynamicParGCStrides is enabled, not sure if that can be encoded 
within the framework) 


If !UseDynamicParGCStrides, then both sets of min / max parameters are not used. I think it’d make the constraint checking a pain having to sanity-check parameters whether a flag is on or off (unless they mean different things in either case, of course).

I added a range check to the min / max stride size args, added a lower bound of 1, and decided to add an artificial upper bound of 32K (I have tested with up to 8K). Is that reasonable? We can revisit that if we need to increse it. Note that you can still set ParGCCardsPerStrideChunk to something higher if required.




- the issues with the Dynamic*Capacity variables Sangheon mentioned, 
although I think it is fine that they are equal, just that "r" needs to 
be set correctly. 


Yeah, fixed. (See previous e-mail.)




Just wanting to check back if it was intended that the code always 
rounds down, achieving the maximum stride only at the end of the 
interval. E.g. 

912 const int stride_size_log = log2_long((jlong) stride_size); 
913 res = (size_t) 1 << stride_size_log; 

It's fine with me, just asking. 


I did the simplest calculation. I can revise it if you want. Also note that if capacity > max_capacity, then stride size will be set to the max stride size.

Tony




Thanks, 
Thomas 









-----

Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprintezis at twitter.com


-----

Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprintezis at twitter.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150708/4e994844/attachment.htm>