RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined

Roland Westrelin roland.westrelin at oracle.com
Fri Dec 19 13:50:12 UTC 2014


From a core file: 

method being compiled is sun.nio.cs.ISO_8859_1::newDecoder 

public java.nio.charset.CharsetDecoder newDecoder(); 
   0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder 
   3: dup 
   4: aload_0 
   5: aconst_null 
   6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."<init>":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V 
   9: areturn 

_exits.control() is a Region node. 
_gvn.type(ret_phi) is top 

ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result above the center line, which filter turns into top.

I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread.


More information about the hotspot-compiler-dev mailing list