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

[Roland Westrelin]

Thanks for the review, Vladimir.

Roland.

> On Dec 22, 2014, at 6:20 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> This looks good.
> 
> Thanks,
> Vladimir
> 
> On 12/22/14 2:43 AM, Roland Westrelin wrote:
>>>> I don't understand how you solved the problem in product build by relaxing the assert.
>>> 
>>> Ok. I thought more about it and that makes sense. I’ll send an updated webrev with a bailout.
>> 
>> Here is a new webrev:
>> http://cr.openjdk.java.net/~roland/8055530/webrev.01/
>> 
>> Roland.
>> 
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 12/19/14 9:58 AM, Roland Westrelin wrote:
>>>>> Thanks for looking at this, Vladimir.
>>>>> 
>>>>>> Why not bailout compilation when you detect such case? You changed only the assert.
>>>>> 
>>>>> I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here?
>>>>> 
>>>>> Roland.
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 12/19/14 5:50 AM, Roland Westrelin wrote:
>>>>>>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/
>>>>>>> 
>>>>>>> From a core file:
>>>>>>> 
>>>>>>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder
>>>>>>> 
>>>>>>> public java.nio.charset.CharsetDecoder newDecoder();
>>>>>>>  Code:
>>>>>>>   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 ab!
>>>>>> ove the ce
>>>>>> nter 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.
>>>>>>> 
>>>>>>> Roland.
>>>>>>> 
>>>>> 
>>> 
>>