Fwd: Tiered compilation and virtual call heuristics

[Carsten Varming]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150722/505e77e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.java
Type: text/x-java
Size: 906 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150722/505e77e4/Main.java>