JDK-8135033 : C1 should fast-path Object.class.isInstance(obj) to null check
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-09-03
  • 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-8130923 - C1 trouble in VarHandle.getObject tests
Description
Current intrinsic code in C1 optimizes Class.isInstance (and Class.cast, transitively) quite well, but it misses an opportunity in optimizing for Object.class case.

Benchmark:
 http://cr.openjdk.java.net/~shade/8135033/ClassCastConstants.java

-XX:TieredStopAtLevel=1:

myClass_inlined       3.766 �� 0.021  ns/op
myClass_staticFinal  3.763 �� 0.002  ns/op
object_inlined         3.086 �� 0.001  ns/op
object_staticFinal  3.106 �� 0.038  ns/op

The disassembly for object_* tests show the redundant compare against Object.class.
Comments
I did an experimental implementation for Aleksey using as separate optimization (see attached patch). It works, but can be probably made to work while parsing as well, which may be more cache-friendly and hence faster.
26-09-2015
A previous attempt to fix this failed: we have to fold Object.class.isInstance(obj) to the null-check, not "true". This is complicated, because canonicalizer does not appear to handle the transformations like these. Igor Veresov suggested we hack GraphBuilder to intercept the node before it is pushed onto the abstract interpretation stack, and replace it with the nullcheck. Or, introduce the LIR node that handles the same. Either way, I have to drop this issue on the floor, given the patch is not as straightforward as originally appeared. This is still important for VarHandles work. Could someone from the compiler team handle this?
26-09-2015
After webrev.00, -XX:TieredStopAtLevel=1: myClass_inlined 3.770 �� 0.034 ns/op myClass_staticFinal 3.768 �� 0.007 ns/op object_inlined 2.616 �� 0.003 ns/op object_staticFinal 2.614 �� 0.062 ns/op
03-09-2015
Webrevs: http://cr.openjdk.java.net/~shade/8135033/
03-09-2015