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

[Jon Masamitsu]

On 06/18/2015 01:19 PM, Tony Printezis wrote:
> Jon,
>
> Is something like this OK?
>
> 3.499: #4: [GC (Allocation Failure) 3.499: #4: [ParNew 
> [ParGCCardsPerStrideChunk: 8192 old_capacity: 18350080K 
> old_capacity_bounds: 1048576K-16777216K stride_size_bounds: 256-8192] 
> : 471872K->52416K(471872K), 0.4452353 secs] 
> 1165095K->921874K(18821952K), 0.4453562 secs] [Times: user=7.20 
> sys=0.03 real=0.45 secs]
>
>

That looks good.

> On June 18, 2015 at 3:30:02 PM, Tony Printezis (tprintezis at twitter.com 
> <mailto:tprintezis at twitter.com>) wrote:
>
>> 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…)
We have some argument checking code that is going in soon so though 
changing to uintx is the right thing,
not right now.

Jon

>> On June 18, 2015 at 3:24:56 PM, Jon Masamitsu 
>> (jon.masamitsu at oracle.com <mailto: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 <mailto: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 <mailto: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
>>>>>>> ofParGCCardsPerStrideChunkthat 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/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Etonyp/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 <mailto:tprintezis at twitter.com>
>>>>>>>>
>>>>>>>
>>>>>> -----
>>>>>>
>>>>>> Tony Printezis | JVM/GC Engineer / VM Team | Twitter
>>>>>>
>>>>>> @TonyPrintezis
>>>>>> tprintezis at twitter.com <mailto:tprintezis at twitter.com>
>>>>>>
>>>>>
>>>>
>>>>
>>>> -----
>>>>
>>>> Tony Printezis | JVM/GC Engineer / VM Team | Twitter
>>>>
>>>> @TonyPrintezis
>>>> tprintezis at twitter.com <mailto:tprintezis at twitter.com>
>>>>
>>>
>> -----
>>
>> Tony Printezis | JVM/GC Engineer / VM Team | Twitter
>>
>> @TonyPrintezis
>> tprintezis at twitter.com <mailto:tprintezis at twitter.com>
>>
> -----
>
> 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/6567166a/attachment.htm>