JDK-6747051 : Improve code and implicit null check generation for comressed oops
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2008-09-10
  • Updated: 2010-04-03
  • Resolved: 2008-10-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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Description
Currently C2 often generats redundant tests against null:

     decode_heap_oop R11,R10
     testl   R10, R10        # compressed ptr
     jeq     B75  P=0.000001 C=-1.000000

decode_heap_oop also contains a test of R10 that's not exposed to the optimizer.
Comments
SUGGESTED FIX Push DecodeN node below the test to the non-null path to use decode_heap_oop_not_null mach node which does not have 0 test. Keep CastPP node for such cases and replace CastPP(DecodeN) with DecodeN clone node with NotNull type during final_graph_reshape phase. This will also allow to generate more implicit null checks with compressed oops. On x86_64 the resulting code will be: movl RDX, [R12 + R10 << 3 + #12] (compressed oop addressing) # range NullCheck R10 And on sparc (requires to pin DecodeN to the non-null path): decode_heap_oop_not_null R_L7, R_O1 LDUW [R_O1 + #12],R_L2 ! range NullCheck R_O1 Also don't compare memory address types in Matcher when DecodeN is consumed by an address expression since types will be different at least by nullness.
24-09-2008
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36ccc817fca4
23-09-2008