JDK-6919064 : Type profiles need to be extended to capture some static arguments
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7,9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2010-01-22
  • 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
Relates :  
JDK-6912064 - type profiles need to be exploited more for dynamic language support
Relates :  
JDK-8015417 - profile pollution after call through invokestatic to shared code
Relates :  
JDK-8015418 - Type profiles should be extended to primitive types
Relates :  
JDK-6919069 - client compiler needs to capture more profile information for tiered work
Relates :  
JDK-8016580 - JSR 292: extend call site profiling to detect stable receiver values
Description
As a follow-on to 6912064 in support of dynamically typed languages, the JVM's type profile needs to capture type information for at least a leading reference operand to an invokedynamic instruction.

If there is no leading reference operand, then either the first leading reference operand (if any) should be profiled, or no profile should be collected.

Also, as long as we're profiling non-receivers  for invokedynamic, let's do it for the other invoke bytecodes also, at least invokestatic.  This should help us better optimize factory methods and other receiver-free patterns.

We can also profile return values.  This will have less benefit than receiver profiling, since if a return value type is useful, it is often used in the context of a subsequent invocation on the object, which would have its own profile that would catch the type.  But, in some cases, a profiled return value would be passed as a non-profiled (non-receiver) argument and used in the inlined body of the callee.  Receiver profiling could reduce the impact of profile pollution (see JDK-8015416).

Profiling more than one argument will require ReceiverTypeData records to include a size parameter.  The footprint impact of such profiles may be costly.  On the other hand, if profiles are only built for warm code the cost may be limited.  Also, if profiles are built for tier one (compiled) code, each reference argument could be assigned its own ad hoc ReceiverTypeData structure.
Comments
This is a very interesting proposal that i think can be put to good use. The hardest problem is still primitive unboxed values in bytecode and how to revert them by way of continuation, but I like this tool.
01-07-2013
Workaround for missing type profiles: Bytecode generators can manually insert new profiling points by adding "checkcast Object" on the value which needs profiling. This bytecode is not emitted by javac. But the JVM will collect a ReceiverTypeProfile for that value, and use it. If the profile point dominates subsequent type checks of any sort, those type checks will be removed, *if* the argument to the checkcast is monomorphic. This applies to the two Class methods (cast, isInstance) and the three type-checking bytecodes (checkcast, instanceof, aastore). Thus, if object code contains too many type tests, one possible cure is to have the initial code generator emit well-chosen "checkcast Object" bytecodes the tested values, at the highest point possible (where the value is expected to be monomorphic). N.B. "Monomorphic" in the JVM means, for some value x, that the expression x.getClass() would return only one Class value. This is a stronger condition than, say, a type-bound assertion like "(Number)x". (M.L., this comment is for you!)
18-06-2013
JSR 292 adapters and other system-generated code (Nashorn?) sometimes uses Class.cast and Class.isInstance as an alternative to checkcast and instanceof bytecodes. Profiling the arguments immediately to the right of 'this' in those Class methods would allow them to be as well-optimized as the bytecodes themselves. (See workaround in next comment, though.) The case of an invokevirtual call to Class, String, or Method is interesting, because those types are 'final' and must therefore have a degenerate type profile for 'this'. It would be reasonable to detect this (when laying out a MethodData) and transfer the profiling to a reference after 'this' (param#1 after param#0), if this reference exists. An extra flag bit in the ReceiverTypeData (now misnamed) would trigger this. There would be no additional memory footprint to hold the improved profiles.
18-06-2013
New JDK 8 code is making frequent use of static methods like Objects.requireNonNull and Objects.equal. If these were open-coded (that is, inlined by hand), the branches and virtual calls (to Object.equals) would be profiled per caller. As global functions, their profiles are polluted, which may cause performance problems. A fix to this bug should demonstrate that Objects.requireNonNull and Objects.equal are as fast as their open-coded equivalents, even in the presence of profile pollution. To pollute the profile of these methods, simply pre-warm the benchmark by a small loop passing a variety of nulls and non-null references to various classes to the arguments of these methods.
14-06-2013