RFR(XL): 6312651: Compiler should only use verified interface types for optimization

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Jul 9 14:11:42 UTC 2019


Hi Roland,

One more failure spotted during testing:

compiler/types/TestMeetExactConstantArrays.java

#  SIGSEGV (0xb) at pc=0x0000000111176328, pid=19481, tid=42755

# Problematic frame:
# V  [libjvm.dylib+0x976328]  LoadNode::make(PhaseGVN&, Node*, Node*, 
Node*, TypePtr const*, Type const*, BasicType, MemNode::MemOrd, 
LoadNode::ControlDependency, bool, bool, bool)+0x550

Stack trace:
   LoadNode::make(PhaseGVN&, Node*, Node*, Node*, TypePtr const*, Type 
const*, BasicType, MemNode::MemOrd, LoadNode::ControlDependency, bool, 
bool, bool)+0x550
   GraphKit::make_load(Node*, Node*, Type const*, BasicType, int, 
MemNode::MemOrd, LoadNode::ControlDependency, bool, bool, bool, bool)+0x128
   BarrierSetC2::load_at_resolved(C2Access&, Type const*) const+0x243
   G1BarrierSetC2::load_at_resolved(C2Access&, Type const*) const+0x121
   BarrierSetC2::load_at(C2Access&, Type const*) const+0x3f
   GraphKit::access_load_at(Node*, Node*, TypePtr const*, Type const*, 
BasicType, unsigned long long)+0xbb
   Parse::array_load(BasicType)+0x10f
   ...

Flags:
   -Xcomp -ea -esa -XX:CompileThreshold=100 
-XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation 
-XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot


The crash is caused by a bottom[] type computed for a merge of Long[] 
and Integer[].

Some output from debugging session:

(lldb) frame info
frame #0: 0x000000010324a07b 
libjvm.dylib`Parse::array_load(this=0x0000700007aace70, 
bt=<unavailable>) at parse2.cpp:71 [opt]


Problematic case:

(lldb) p array->dump(1)

  81	ConP	===  0  [[ 76  71  96 ]]  #narrowoop: java/lang/Long 
(java/io/Serializable,java/lang/Comparable,java/lang/constant/Constable,java/lang/constant/ConstantDesc):exact 
*[int:1] (java/io/Serializable,java/lang/Cloneable)<ciObjArray length=1 
type=<ciObjArrayKlass name=[Ljava/lang/Long; ident=1167 
address=0x00000001298700d0> ident=1170 address=0x00000001298705d0> *
  93	ConP	===  0  [[ 88  96 ]]  #narrowoop: java/lang/Integer 
(java/io/Serializable,java/lang/Comparable,java/lang/constant/Constable,java/lang/constant/ConstantDesc):exact 
*[int:1] (java/io/Serializable,java/lang/Cloneable)<ciObjArray length=1 
type=<ciObjArrayKlass name=[Ljava/lang/Integer; ident=1165 
address=0x000000012986f300> ident=1173 address=0x0000000129870910> *
  94	Region	===  94  45  57  [[ 94  98  95  96  97 ]]  !jvms: 
TestMeetExactConstantArrays::loopNumbers @ bci:-1
  96	Phi	===  94  93  81  [[ 83  100  100  110  118  131  144  159  159 
160  160  172  172  178  178  184  184 ]]  #bottom[int:1] 
(java/io/Serializable,java/lang/Cloneable):NotNull * !jvms: 
TestMeetExactConstantArrays::loopNumbers @ bci:-1


Original behavior:

(lldb) p array->dump(1)
  81	ConP	===  0  [[ 76  71  96 ]]  #narrowoop: java/lang/Long:exact 
*[int:1]<ciObjArray length=1 type=<ciObjArrayKlass 
name=[Ljava/lang/Long; ident=1144 address=0x000000010098f2d0> ident=1147 
address=0x000000010098f7d0> *
  93	ConP	===  0  [[ 88  96 ]]  #narrowoop: java/lang/Integer:exact 
*[int:1]<ciObjArray length=1 type=<ciObjArrayKlass 
name=[Ljava/lang/Integer; ident=1142 address=0x000000010098e500> 
ident=1150 address=0x000000010098fb10> *
  94	Region	===  94  45  57  [[ 94  98  95  96  97 ]]  !jvms: 
TestMeetExactConstantArrays::loopNumbers @ bci:-1
  96	Phi	===  94  93  81  [[ 83  100  100  110  118  131  144  159  159 
160  160  172  172  178  178  184  184 ]]  #narrowoop: java/lang/Number 
*[int:1]:NotNull * !jvms: TestMeetExactConstantArrays::loopNumbers @ bci:-1

Best regards,
Vladimir Ivanov

On 05/07/2019 11:50, Roland Westrelin wrote:
> 
> Hi Vladimir,
> 
>> I believe the culprit here is that I observe the failures on MacOS only.
>> I have no idea why it doesn't show up on Linux.
> 
> Indeed, I can reproduce it on macos. The issue is some of the code I
> added rely on evaluation ordering of arguments to some method and that
> differs with llvm.
> 
> Anyway, here is a new webrev that should fix all failures you
> encountered and rebased to current jdk/jdk:
> 
> http://cr.openjdk.java.net/~roland/6312651/webrev.01/
> 
> Roland.
> 


More information about the hotspot-compiler-dev mailing list