RFR(S) 8058564: Tiered compilation performance drop in PIT
igor.veresov at oracle.com
Wed Sep 17 09:35:02 UTC 2014
Sorry, my fix is not entirely good. MethodCounters should exist before a method ends up in compile queue. I’ll get back with the updated webrev.
On Sep 17, 2014, at 2:01 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> We don’t always have MDOs. Level 1 & 2 are good examples. C2 also doesn’t always require an MDO.
> I also wanted it to work with other compilers, like Graal. By putting this logic in the policy it’s in one place and I don’t need to touch compilers. I could’ve put it in the broker, but it seemed that these level values are artifacts of the policy so it seems reasonable to put it in the policy.
> On Sep 17, 2014, at 12:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> Why not create MethodCounters in Method::build_interpreter_method_data()? It is called at the beginning of compilation (C1 and C2) from ciMethod::ensure_method_data(). And not necessary that way. My point is - why not crate them at the beginning of a compilation as we do with MDO? Compiled code may need to access it. May be not now but in a future.
>> On 9/17/14 12:39 AM, Igor Veresov wrote:
>>> The problem here is that with -Xcomp we immediately compile a method at level 3, and we’re not creating MethodCounters since we never execute in the interpreter and hence not setting the “highest” level values. The solution is to allocate MethodCounters for every method compiled (unless it has been allocated naturally by the interpreter). I made it in a form of a callback to the policy, since only tiered policies cares about these values.
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8058564
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8058564/webrev.00
More information about the hotspot-compiler-dev