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

[Tony Printezis]

Sangheon,

Thanks, well spotted. I did what Thomas suggested: allow the diff to be 0 and make sure r is 0.0 when that happens.

FYA: I tried to cause the issue by setting min_capacity == max_capacity and I couldn’t. Note the start of that method: the calculation only takes place when min_capacity <= capacity <= max_capacity. So, if min_capacity == max_capacity, both have to be == capacity for the calculation to happen which will cause the div-by-0. :-)

Anyway, thanks again for bringing this up,

Tony

On July 1, 2015 at 8:03:32 PM, sangheon.kim (sangheon.kim at oracle.com) wrote:

Hi Tony,

I just looked the calculation routine and if we set 'DynamicParGCStridesMinOldGenCapacity = DynamicParGCStridesMaxOldGenCapacity', division by zero would happen.
So if I understand correctly, the constraint of 'max' should be always greater than 'min', isn't it?

http://cr.openjdk.java.net/~tonyp/8086056/webrev.2/src/share/vm/gc/cms/parNewGeneration.cpp.frames.html

 885   const size_t min_old_gen_capacity = DynamicParGCStridesMinOldGenCapacity;
 886   const size_t max_old_gen_capacity = DynamicParGCStridesMaxOldGenCapacity;

 902     const size_t capacity_diff = max_old_gen_capacity - min_old_gen_capacity;
 903     const size_t capacity_offset = capacity - min_old_gen_capacity;
 904     const double r = (double) capacity_offset / (double) capacity_diff;

Thanks,
Sangheon


On 07/01/2015 03:05 PM, Tony Printezis wrote:
Latest changes, as discussed with Bengt and Thomas,

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

Tony

On June 26, 2015 at 9:37:45 AM, Thomas Schatzl (thomas.schatzl at oracle.com) wrote:

Hi Tony,

On Fri, 2015-06-26 at 09:30 -0400, Tony Printezis wrote:

[...]
> >
> >
> > The JEP says:
> >
> > "The range and constraints checks are done every time a flag
> > changes, as well as late in the JVM initialization routine (i.e., in
> > init_globals() after stubRoutines_init2()) at the time when all
> > flags have their final values set. We will continue to check the
> > manageable flags as long as the JVM runs."
> >
> > I haven't actively been using this myself, but I assume that the
> > constraints will be checked every time a managaeble flag is changed
> > and that the one trying to change it will get an error reported back
> > if they try to change it in an invalid way.
> >
> > I'm copying Gerard on this email. He has built this support and can
> > surely answer the details.
>
> Hi, thanks. I’ll definitely look at it and change the code
> appropriately. BTW, has the change been integrated into the hs gc repo
> yet? (I don’t see it so I assume it hasn't.)

You overlooked that a week or two ago we started to try out merging the
hs-rt and hs-gc repos to test whether doing so is beneficial in terms of
maintenance etc.

So the hs-gc repo is currently discontinued. Please rebase your changes
to hs-rt. :)

[...]
> >
> > Finally, just a heads up. I will be on vacation for the coming three
> > weeks. I doubt that I will be able to review any new version during
> > that time. If you get reviews from others I'm perfectly fine with
> > this being pushed. Depending on how different the changes that you
> > push are compared to the versions I've reviewed I'll leave it up to
> > you to decide whether you want to list me as a reviewer or not. I'm
> > fine either way. It's not a problem to leave me out of the reviewer
> > list if you are unsure.
>
> OK, thanks for letting me know! And enjoy your time off!!!!

I will take over :)

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/20150702/0288a2d7/attachment.htm>