[9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation)

[Vladimir Kozlov]

Zoltan,

Please, add test. There is -XX:+PrintFlagsFinal which will print all 
flags after all adjustments so you can verify that thresholds flags are 
correctly scaled. Check CompileThresholdScaling value corner cases too.

Also I would like to see explicit casts to (intx) after multiplication.
May be add an other Arguments method which do just multiplication by 
CompileThresholdScaling and cast to return intx.

Thanks,
Vladimir

On 10/10/14 12:53 AM, Zoltán Majó wrote:
> Thank you, Igor, for the review.
>
> Could somebody please provide a second Reviewer's review? I think the
> change is too large to be pushed with only one "Review".
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
> On 10/09/2014 08:58 PM, Igor Veresov wrote:
>> That looks good to me.
>>
>> igor
>>
>> On Oct 9, 2014, at 9:43 AM, Zoltán Majó <zoltan.majo at oracle.com> wrote:
>>
>>> Hi Igor,
>>>
>>>
>>> thank you for your feedback!
>>>
>>> On 10/07/2014 11:17 PM, Igor Veresov wrote:
>>>> 1. It would probably be nice not to do multiplications at every
>>>> event but rather compute everything once during the startup. Perhaps
>>>> it would be better to scale command line options right in
>>>> arguments.cpp ? Or setup accessors in Arguments that would compute
>>>> and cache the values. If you just scale the options the change would
>>>> be smaller though. What do you think?
>>> That is a good idea. I changed the code to scale thresholds in
>>> arguments.cpp (in Arguments::apply_ergo()).
>>>
>>>> 2. Why aren’t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog
>>>> and Tier23InlineeNotifyFreqLog? Probably can be solved by (1)
>>>> automatically.
>>> The previous patch adjusts only the transition from Tier 0 to Tier 3
>>> (when methods get first compiled). But now that you've suggested, I
>>> extended the patch to scale Tier4* compilation thresholds and
>>> Tier{2,3} notification thresholds as well.
>>>
>>> Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/
>>>
>>> I tested the new patch with JPRT and manual testing.
>>>
>>> Thank you and best regards,
>>>
>>>
>>> Zoltan
>>>
>>>> igor
>>>>
>>>> On Oct 7, 2014, at 6:45 AM, Zoltán Majó<zoltan.majo at oracle.com>  wrote:
>>>>
>>>>> Hi Albert,
>>>>>
>>>>>
>>>>> thank you for your feedback.
>>>>>
>>>>> On 10/07/2014 12:56 PM, Albert Noll wrote:
>>>>>> How about using a scaling factor instead of using percentage?
>>>>> I think that is a good idea because a scaling factor (expressed as
>>>>> a double) allows a finer-grained control of compilation thresholds
>>>>> than a scaling percentage (expressed as an integer).
>>>>>
>>>>> Here is the webrev with the scaling factor:
>>>>>
>>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/
>>>>>
>>>>> The name of the flag is changed to CompileThresholdScaling (from
>>>>> CompileThresholdScalingPercentage).
>>>>>
>>>>>> What happens if a threshold becomes 0 after scaling?
>>>>> Then all methods will be interpreted. That seems to be the
>>>>> convention (in src/share/vm/runtime/arguments.cpp).
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Zoltan
>>>>>
>>>>>> Best,
>>>>>> Albert
>>>>>>
>>>>>>
>>>>>> On 10/07/2014 12:32 PM, Zoltán Majó wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> please review the following patch.
>>>>>>>
>>>>>>>
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604
>>>>>>>
>>>>>>>
>>>>>>> Problem: With tiered compilation enabled, the value of 6
>>>>>>> different thresholds must be set to control when the JVM compiles
>>>>>>> methods for the first time. That is too detailed for the average
>>>>>>> customer.
>>>>>>>
>>>>>>>
>>>>>>> Solution: This patch adds a new flag,
>>>>>>> CompileThresholdScalingPercentage, to control when methods are
>>>>>>> first compiled. The new flag scales thresholds the following way:
>>>>>>>
>>>>>>> - if CompileThresholdScalingPercentage==100, the default
>>>>>>> threshold values are used
>>>>>>> - if CompileThresholdScalingPercentage>100, threshold values are
>>>>>>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up
>>>>>>> thresholds by a factor of 1.2X)
>>>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold
>>>>>>> values are scaled down accordingly.
>>>>>>>
>>>>>>> The new flag works both with and without tiered compilation.
>>>>>>> Thus, the new flag allows compilation to be controlled the same
>>>>>>> way both with and without tiered compilation:
>>>>>>>
>>>>>>> - with tiered compilation enabled, the value of the flags
>>>>>>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog,
>>>>>>> Tier3InvocationThreshold, Tier3MinInvocationThreshold,
>>>>>>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled
>>>>>>>
>>>>>>> - with tiered compilation disabled, the value of CompileThreshold
>>>>>>> is scaled
>>>>>>>
>>>>>>> Currently, tiered and non-tiered compilation treats threshold
>>>>>>> values slightly differently: For a threshold value of N and
>>>>>>> without tiered compilation enabled, methods are compiled *before*
>>>>>>> their Nth execution. With tiered compilation enabled, methods are
>>>>>>> compiled *after* the their Nth execution.
>>>>>>>
>>>>>>> The patch addresses the difference between tiered/non-tiered
>>>>>>> compilation: Methods are compiled right before their Nth
>>>>>>> execution in both cases (the non-tiered way). If
>>>>>>> CompileThresholdScalingPercentage==0, all methods are interpreted
>>>>>>> (similarly to the case when CompileThreshold==0).
>>>>>>>
>>>>>>> This patch is the second (out of three) parts of JDK-8050853
>>>>>>> (adding support for per-compilation
>>>>>>> thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853  .
>>>>>>>
>>>>>>>
>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>> Testing: JPRT, manual testing
>>>>>>>
>>>>>>>
>>>>>>> Thank you and best regards,
>>>>>>>
>>>>>>>
>>>>>>> Zoltan
>>>>>>>
>