JDK-8015418 : Type profiles should be extended to primitive types
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-05-25
  • 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-8015416 - tier one should collect context-dependent split profiles
Relates :  
JDK-6919064 - Type profiles need to be extended to capture some static arguments
Description
Although type profiling only applies to references, in some cases it would be profitable to profile primitive values, especially ints.

Any primitive can be summarized in two words as accumulated min and max, and/or as two words of bitwise logical and and bitwise logical or.  A few statistical moments (at least order 0 and 1, maybe 2 if multiplies can be tolerated) can also be captured.

Certain bytecodes that interact with loops can be instrumented this way to allow optimistic range reduction at compile time.  Candidates would be *aload, if*, *cmp*, get*, *newarray, and arraylength.

If references that are non-receiver method arguments or return values are profiled, the profiling could be extended to primitives.  (See JDK-6919064.)

If the cost (space or time) of gathering this data is prohibitive, consider doing it only in tier one compiled code.  (See JDK-8015416.)