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

[Tom Rodriguez]

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.