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

sangheon.kim sangheon.kim at oracle.com
Thu Jul 2 00:03:28 UTC 2015


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/ 
> <http://cr.openjdk.java.net/%7Etonyp/8086056/webrev.2/>
>
> Tony
>
> On June 26, 2015 at 9:37:45 AM, Thomas Schatzl 
> (thomas.schatzl at oracle.com <mailto: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 <mailto:tprintezis at twitter.com>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150701/0230aac3/attachment.html>


More information about the hotspot-gc-dev mailing list