Tiered compilation and virtual call heuristics

[Igor Veresov]

I guess you got a little bit unlucky :). Increasing BciProfileWidth will only work in the case when one of the types appears in the profile later and then dominates other usages (see TypeProfileMajorReceiverPercent, it’s 90% by default). So, by the time C2 see the callsite the receiver type you want should be recorded and have more than 90% of counts. The overhead of BciProfileWidth may be substantial for the startup (slower profiling), but it won’t affect the final code (unless inlining happens differently, in a bad way).

Another approach would be to delay the moment when the profiling starts. By, basically, bumping up the values of these guys:

  product(intx, Tier3InvocationThreshold, 200,                              \
          "Compile if number of method invocations crosses this "           \
          "threshold")                                                      \
                                                                            \
  product(intx, Tier3MinInvocationThreshold, 100,                           \
          "Minimum invocation to compile at tier 3")                        \
                                                                            \
  product(intx, Tier3CompileThreshold, 2000,                                \
          "Threshold at which tier 3 compilation is invoked (invocation "   \
          "minimum must be satisfied)")                                     \


Compilation will happen, when the following predicate gets true:

    return (i >= Tier3InvocationThreshold * scale) ||
           (i >= Tier3MinInvocationThreshold * scale && i + b >= Tier3CompileThreshold * scale);

Here, i is invocations, b is backedges, scale is something dynamic but is >= 1.


igor

> On Jul 22, 2015, at 10:37 AM, Carsten Varming <varming at gmail.com> wrote:
> 
> Dear Hotspot compiler group,
> 
> I have had a few issues with tiered compilation in JDK8 lately and was wondering if you have some comments or ideas for the given problem.
> 
> Here is my problem as I currently understand it. Feel free to correct any misunderstandings I may have. With tiered compilation the heuristics for inlining virtual calls seems to degrade quite a bit. I think this is due to MethodData objects being created much earlier with tiered than without. This causes the tracking of the hottest target methods at a virtual call site to go awry, due to the limit (2) on the number of MethodData objects that can be associated with a bci in a method. It seems like the only virtual call targets tracked are the targets that are warm when when C1 is invoked.
> 
> The program ends up with all call-sites in scala.collection.IndexedSeqOptimized.slice using virtual dispatch with tiered and bimorphic call sites without tiered. The end result with tiered is a tripling of the cpu required to run the program, and instruction pointers from the compiled slice method end up in 90% of all cpu samples (collected with perf at 4kHz).
> 
> The problem is with a small application built in Scala on top of Netty. I have written a small sample program (see attached Main.java) to spare you the details (and to be able to give you code).
> 
> When I run the sample program with tiered then the call to count end up being a virtual call, due to Instance$3.count  and Instance4.count being warm when C1 kicks in. Without tiered Instance$1.count is the only hot method.
> 
> I wonder if you guys have seen this problem in the wild or if I just happen to be unlucky. Increasing BciProfileWidth should help in my case, but it is not a product flag. Do you have any experience regarding cost of increasing BciProfileWidth? Do you have any thoughts on throwing out MethodData objects for virtual call sites that turns out to be pretty cold?
> 
> Thank you in advance for your thoughts,
> Carsten
> 
> <Main.java>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150723/fafdf076/attachment.html>