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

[Tony Printezis]

OK, will do (6 new cmd line args now… I’m loving it!)

BTW, would anyone object if I change ParGCCardsPerStrideChunk from intx to uintx? (it really should not be negative…)

On June 18, 2015 at 3:24:56 PM, Jon Masamitsu (jon.masamitsu at oracle.com) wrote:



On 06/18/2015 11:49 AM, Tony Printezis wrote:
Jon,

Inline.

On June 18, 2015 at 1:22:47 PM, Jon Masamitsu (jon.masamitsu at oracle.com) wrote:



On 06/18/2015 06:27 AM, Tony Printezis wrote:
Hi Jon,

Thanks for looking at it. I can definitely add an additional bool flag to turn it on or off. I think it will also make sense to make it manageable so that we can switch the auto-tuning on / off dynamically, if necessary.

Thanks.

When you were doing the performance testing, did you have some type of logging
so that you could see the cards-per-stride-chunk that was being used?   


Yes, I had ad-hoc output for that.



Eventually
someone is going to ask for it so if you had something succinct I'd be glad to see it
included in this push.


I think it’d be helpful, but I’d be apprehensive adding more GC log output that will mess up GC logs even more. :-) Any suggestions on maybe some existing output I could piggy-back this on?


Add the logging under (yet another) flag.  We're trying to move to the new logging format and doing
so will likely reduce such concerns.  I'd like something there to be converted to the new format.

Thanks.

Jon

Tony




Jon

Tony

On June 17, 2015 at 9:46:16 PM, Jon Masamitsu (jon.masamitsu at oracle.com) wrote:

Tony,

I'm still studying the patch but would you consider a more explicit
flag to turn this on and off?  What you have is very reasonable but
if the performance team sees some regression, it would be easier
for them to turn the feature on or off rather than go look for the value
of ParGCCardsPerStrideChunk that is the default and then put that
on the command line.  Same would be true for a customer who has
an application operating in one of the corners where the performance
is worse.

Jon
 
On 6/17/2015 3:30 PM, Tony Printezis wrote:
Hi all,

A small patch for your consideration:

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

(BTW, for some reason some of the webrev output is a bit messed up. Not sure why, maybe some hg incompatibility I guess. The diffs look OK though. I also attached the patch to this e-mail.)

There’s a bit of info on the JIRA on the rationale for the patch:

https://bugs.openjdk.java.net/browse/JDK-8086056

The min / max values for the old gen capacity and ParGCCardsPerStrideChunk were chosen empircally after running a few (mostly synthetic tests) on Linux x64. If someone has the cycles to do a more extensive performance study, I’d be happy to revise them accordingly.

Regards,

Tony

-----

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




-----

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/20150618/68c71c87/attachment.htm>