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

Zoltán Majó zoltan.majo at oracle.com
Tue Oct 7 13:47:27 UTC 2014


P.S.: Forgot to say that the new version (webrev.01) passes all JPRT tests.

On 10/07/2014 03:45 PM, Zoltán Majó 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