review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld

[Tom Rodriguez]

I just realized why this doesn't work.  T_LONG is two local slots but T_ADDRESS is only one so to deopt properly you need a single slot 64 bit value which is what T_ADDRESS ends up representing.  So I'm sticking with the fix as reviewed.  Thanks!

tom

On Sep 22, 2010, at 3:51 PM, Tom Rodriguez wrote:

> Actually I may retract this.  I think there might be a simpler way to handle this by changing the original fix for 6932496.  We used to just treat T_ADDRESS as T_INT but that didn't allow deopt to work correctly because T_ADDRESS is pointer sized because of the use of astore.  It seems like we should just be able to treat it as T_LONG in 64 bit and have it all work out fine.  I'd rather not introduce T_ADDRESS into LIR_Opr just for this.
> 
> tom
> 
> On Sep 22, 2010, at 3:20 PM, Vladimir Kozlov wrote:
> 
>> I did not know that it doesn't effect code generation.
>> Then it is good to push.
>> 
>> Thanks,
>> Vladimir
>> 
>> Tom Rodriguez wrote:
>>> On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote:
>>>> Tom,
>>>> 
>>>> Changes looks good.
>>>> Did you test 64-bit C1 which could be affected by these changes?
>>> No i didn't but it's really about abstract typing in the LIR and doesn't effect code generation.  I can run CTW if you want.
>>> tom
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> Tom Rodriguez wrote:
>>>>> http://cr.openjdk.java.net/~never/6972540
>>>>> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld
>>>>> Reviewed-by:
>>>>> The fix 6932496 exposed T_ADDRESS as a constant so that deopt with
>>>>> jsr's could work properly.  Since it didn't fully expose T_ADDRESS as
>>>>> a support lir type it create type mismatches that showed up in some
>>>>> complex cases.  The fix is support T_ADDRESS in the LIR directly.
>>>>> Tested with full CTW.
>