RFR: JDK-8086056: ParNew: auto-tune ParGCCardsPerStrideChunk
Bengt Rutisson
bengt.rutisson at oracle.com
Thu Jun 18 07:02:43 UTC 2015
Hi Tony,
NIce to hear from you!
On 18/06/15 00:30, Tony Printezis wrote:
> Hi all,
>
> A small patch for your consideration:
>
> http://cr.openjdk.java.net/~tonyp/8086056/webrev.0/
> <http://cr.openjdk.java.net/%7Etonyp/8086056/webrev.0/>
A couple of style comments:
891 const size_t MinOldGenCapacity = G;
892 const size_t MaxOldGenCapacity = 16 * G;
893 assert(MinOldGenCapacity <= MaxOldGenCapacity, "sanity");
Local variables are normmaly named using lower case and underscore. So,
min_old_gen_capacity and max_old_gen_capacity. Same for the rest of the
local variables in ParNewGeneration::adjust_cards_per_stride().
Having said that, I think it would be good to turn some of these
constants into flags (which means that the naming should be as it is now
;) ). Especially since you say that you haven't done much performance
testing of these values. I would prefer that we could adjust them at
runtime. Best would of course be if you could take the time to do the
performance testing.
I realize that the assert on line 893 might have been useful if you were
playing around with the numbers when you were experimenting with the
patch. But now it looks mostly like line noise to me. Same with the
assert on line 898.
I would also consider factoring the actual computation out into a
separate helper method.
I also second Jon's comment on that it would be good with a more
explicit way of turning this feature off.
Thanks,
Bengt
>
> (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 <mailto:tprintezis at twitter.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150618/84e8fb87/attachment.htm>
More information about the hotspot-gc-dev
mailing list