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

[Zoltán Majó]

Hi Vladimir,


thank you for your comments!

On 10/10/2014 10:19 PM, Vladimir Kozlov wrote:
> 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.

I added compiler/arguments/CheckCompileThresholdScaling.java to check 
the scaling of flags.

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

I added a new function, Arguments::get_scaled_compile_threshold(), that 
does the scaling and also casts the result of the scaling explicitly.

Here is the updated webrev:

http://cr.openjdk.java.net/~zmajo/8059604/webrev.03/

All JPRT tests pass.

Thank you and best regards,


Zoltan

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