United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6747051 Improve code and implicit null check generation for comressed oops
6747051 : Improve code and implicit null check generation for comressed oops

Details
Type:
Enhancement
Submit Date:
2008-09-10
Status:
Resolved
Updated Date:
2010-04-03
Project Name:
JDK
Resolved Date:
2008-10-07
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs14
Fixed Versions:
hs14

Related Reports
Backport:
JDK-2177294 - Improve code and implicit null check generation for comressed oops
Backport:
JDK-2172800 - Improve code and implicit null check generation for comressed oops

Sub Tasks

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.
2008-09-24 
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/36ccc817fca4
2008-09-23


Hardware and Software, Engineered to Work Together