[9] RFR(S): 8059606: Enable per-method usage of CompileThresholdScaling (per-method compilation thresholds)
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Jan 5 19:13:59 UTC 2015
On 1/5/15 10:38 AM, Zoltán Majó wrote:
> Hi,
>
>
> please review the following patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8059606
>
> Problem: Controlling compilation thresholds on a per-method level can be useful for debugging and understanding
> failures, but currently there is no way to control on a per-method level when methods are compiled.
>
>
> Solution:
>
> This patch adds support for scaling compilation thresholds on a per-method level using the CompileThresholdScaling flag.
> For example, the option
>
> -XX:CompileCommand=option,SomeClass.someMethod,double,CompileThresholdScaling,0.5
>
> reduces compilation thresholds for method SomeClass.sometMethod() by 50% (but leaves global thresholds unaffected) and
> results in earlier compilation of the method.
>
> Similar to the global CompileThresholdScaling flag (added in JDK-805604), the per-method CompileThresholdScaling flag
> works with both tiered and non-tiered modes of operation.
>
> Per-method compilation thresholds are available only in non-product builds to avoid the overhead of accessing fields
> added by the patch MethodData and MethodCounters.
Too many ifdefs :)
The interpreter speed is not important. And the feature could be interesting in product VM too.
The only drawback is 2 additional fields in MDO which is fine.
Can you make it product and run through our performance infrastructure.
Also, as John Rose will say, we should have as much as possible a similar code in product as in tested debug code.
Otherwise we are not testing product bits and will get into troubles.
>
> The proposed patch supports x86_64, x86_32, and sparc. Do you think it is necessary to support other architectures as well?
Yes. It should be supported on all platforms.
>
> The patch updates the name of the flags Tier2BackEdgeThreshold, Tier3BackEdgeThreshold, Tier4BackEdgeThreshold
> (lowercase e in "Back*e*dge) so that the naming is consistent with other backedge-related flags
> (Tier0BackedgeNotifyFreqLog, Tier2BackedgeNotifyFreqLog, and Tier3BackedgeNotifyFreqLog).
It added noise to main changes and may cause some testing (jfr?) failures. Can we do it separately (other RFE?).
>
> This patch is the third (and final) part of JDK-8050853: https://bugs.openjdk.java.net/browse/JDK-8050853 .
>
>
> Webrev: http://cr.openjdk.java.net/~zmajo/8059606/webrev.00/
In general looks good.
Thanks,
Vladimir
>
> Testing: manual testing on all supported architectures, JPRT.
>
> Thank you and best regards,
>
>
> Zoltan
>
More information about the hotspot-compiler-dev
mailing list