JDK-7170463 : C2 should recognize "obj.getClass() == A.class" code pattern
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-05-21
  • Updated: 2013-06-26
  • Resolved: 2012-06-16
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
R��mi Forax wrote:

This pattern is used to implement an inlining cache using invokedynamic,
it's used in most of the dynamic runtimes that used invokedynamic, JRuby, Groovy and
Mark Roos's SmallTalk to cite a few.
With this patch, implementing invokeinterface with invokedynamic produces the exact same code
as invokeinterface which demonstrate that after being JITed invokedynamic has no overhead.
Krystal Mok wrote:

The idea is to optimize this code pattern:

  x.getClass() == A.class


  x._klass == klassof(A)

which shortens the original pattern by 1 load.

A scenario where this might be useful is the following code pattern:

  if (x.getClass() == A.class) {
    A a = (A) x; // checkcast
    a.m();       // ... use a ...

Before this change, there would be redundant exact type check in the generated code, as mentioned in an earlier thread [1].
After this change, the redundant check gets optimized away, because the new pattern is the same as the one used in the fast path of instanceof/Class.isInstance()/checkcast.

It's probably rare to see this pattern in normal Java code, where normal virtual dispatch should be favored instead. But it might be a common pattern in dynamic language runtime implementations.
I'll leave it to Remi to explain the original motivation for optimizing this code pattern :-)

Tested with CTW -XX:+VerifyIterativeGVN, and SPECjvm2008.
The composite result in SPECjvm2008 seems to have dropped a little bit, I'm not sure if that's caused by this change or by some variance on my test machine.


[1]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-April/007568.html

EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8f6ce6f1049b

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f6ce6f1049b