If M calls Objects.equals(x, y), then the call to x.equals(y) inside the Objects.equals must use a polluted profile.

If (in addition) x and y have no inferred type in M, then even if Objects.equals is inlined, there is no way to optimistically type x.

If M calls x.equals(y) directly, then the invokevirtual instruction in M is a profile point which can contribute the useful type information for x (but not y).

There are two possible solutions; either or both could be taken:

1. Add profiling to invokestatic, if the first argument is a reference. This is JDK-6919064 .

2. Add split profiles to tiered code. This is JDK-8015416 .

A plausible metric for success is that a micro benchmark that calls Objects.equals(x,y) is comparable in speed to one that calls x.equals(y) directly, even when the global type profile for Object.equals is polluted by warm-up calls to objects of a variety of types.

Notes:

See also https://cr.openjdk.org/~jrose/jvm/equals-profile.html

The same considerations apply to invokedynamic as for invokestatic, since those two instructions have no stacked receiver argument.

Suggestion #1 aims at the common case of a leading reference parameter, but will not help if the method takes no arguments, or if its first argument is not a reference. Suggestion #2 allows more precise collection of type information, assuming that tier-one inlining has reached all relevant invokevirtual instructions.

The checkcast, instanceof, and aastore instructions were profiled as of JDK-6516101 and JDK-6912064 .

Global profiling was added to tier one as of JDK-6919069 and JDK-7091764 . Split profiling is requested by /JDK-8015416 .