JDK-8015417 : profile pollution after call through invokestatic to shared code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-05-25
  • Updated: 2019-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
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:

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 .