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

[Jon Masamitsu]

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>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150618/2496da73/attachment.htm>