[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