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.
JDK 8 JDK 9
8u20Fixed 9 b02Fixed
Description
With this class hierarchy:
    static class A {
        void m() {}
    }

    static class B extends A {
    }

and this java code:
A a
a.m();

the profile that is collected for the receiver is A if even a is really a B.
Comments
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.
07-01-2014

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.
07-01-2014

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.
12-11-2013