[9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation)
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Oct 14 20:43:31 UTC 2014
This looks good.
Thanks,
Vladimir
On 10/14/14 11:16 AM, Zoltán Majó wrote:
> 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
>>>>>>>>>
>>>
>
More information about the hotspot-compiler-dev
mailing list