JDK-8016580 : JSR 292: extend call site profiling to detect stable receiver values
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8,9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-06-13
  • Updated: 2018-10-05
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
Duplicate :  
JDK-8058319 - No value profile for receivers: constructor MethodHandle invocation is very slow
Relates :  
JDK-6919064 - Type profiles need to be extended to capture some static arguments
Relates :  
JDK-8016581 - JSR 292: invokeExact (invokehandle) operations should profile method handle behavior forms
Description
Some call sites, especially in dynamic languages or delegation-based systems, are not only monomorphic in type, but also have stable receiver values.  In other words, the same receiver ('this') is always used at the call site.  If this condition can be detected, the JIT can optimistically compile code which knows not only the type of the receiver (as with monomorphic call sites) but also the identity of the receiver, including all final (or otherwise stable) fields.

This may be especially useful with method handles, where the JIT is able to inline the entire behavior of a method handle graph, once it is given a constant root of the graph.

It may also be useful for programs which use "golden objects", i.e., a class with a single instance.  (There are simpler ways of detecting and optimizing golden objects, however.)
Comments
Applying this optimization to all call sites would add at least a word of overhead per warmed invokevirtual/invokeinterface. That may be acceptable, but it is probably a better idea to overlay the storage on top of the Klass* pointers in the profile. That is, as long as just one or two distinct instances are encountered, the profile stores those (as weak references), but as soon as it overflows, we switch to Klass* pointers and hope for better results with that tactic. Another option would be to allocate a special bytecode for just those methods which we expect to encounter usefully stable receiver values. (Example: jlr.Method.invoke, jlr.Constructor.newInstance.) An "invokevirtual_same_receiver" code would be in all respects equivalent to "invokevirtual", except that the MDO would allocate more profile space to detect and record the stable receiver values.
26-03-2014
8-pool is an invalid affects version. Set 8 and hs25.
12-11-2013