RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling

Igor Veresov igor.veresov at oracle.com
Wed Nov 6 16:10:06 PST 2013

Looks good.


On Nov 6, 2013, at 8:53 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> http://cr.openjdk.java.net/~roland/8027631/webrev.00/
> The c1 profile collection code relies on the signature of the callee to figure out whether there’s a single possible class for an argument (to then not emit code that deal with conflicting profiles). The problem is that at a method handle invoke, a single call site can call different methods with different signature. So using the callee signature is not correct even though it can still be useful because it provides information about the types of arguments/return value. This change uses the signature from the call site to decide whether a single class is possible and the signature of the callee to improve the type of the arguments/return value more. The test case revealed another problem with profiling: profiling of arguments at a method handle call should skip over the first argument if the call is to a static method from a virtual method handle method because it’s not an argument at the call.
> Roland.

More information about the hotspot-compiler-dev mailing list