JDK-8028064 : tiered may collect wrong receiver type at virtual call
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-11-08
  • Updated: 2014-07-29
  • Resolved: 2014-01-07
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.
8u20Fixed 9 b02Fixed
With this class hierarchy:
    static class A {
        void m() {}

    static class B extends A {

and this java code:
A a

the profile that is collected for the receiver is A if even a is really a B.
Regarding the lack of test case: there's no way to check that collect profiling is incorrect as it doesn't affect correctness of code execution. We would need to check the output of -XX:+PrintMethodData.

When there���s a unique possible callee method, tiered optimizes profile collection by using the callee���s holder as unique possible class. That���s incorrect. The class itself should be tested as being final or leaf.

This issue should not affect c2's inlining as it happens when the target method is known so when c2 doesn't need profiling. It could affect type speculation.