review (S) for 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld
tom.rodriguez at oracle.com
Wed Sep 22 17:15:40 PDT 2010
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!
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.
> 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.
>> Tom Rodriguez wrote:
>>> On Sep 22, 2010, at 2:46 PM, Vladimir Kozlov wrote:
>>>> 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 Rodriguez wrote:
>>>>> 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld
>>>>> 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.
More information about the hotspot-compiler-dev