Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC

Tom Rodriguez tom.rodriguez at oracle.com
Tue Oct 12 10:01:19 PDT 2010


On Oct 12, 2010, at 9:41 AM, Christian Thalinger wrote:

> On 10/12/10 6:36 PM, Tom Rodriguez wrote:
>> 
>> On Oct 12, 2010, at 8:49 AM, Christian Thalinger wrote:
>> 
>>> On 9/30/10 7:45 PM, Christian Thalinger wrote:
>>>> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote:
>>>>> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote:
>>>>> 
>>>>>> Why aren't the values dependent on which operation is being performed then?
>>>>> 
>>>>> They certainly can be.  That will move the complication out of the
>>>>> assembly code. (And into methodHandles.cpp, with a new CPU-specific
>>>>> query, plus a new but useful distinction between value conversion and
>>>>> unboxing.)  I'm fine with doing it either way.
>>>> 
>>>> I will look into that and try to come up with a new patch.
>>> 
>>> http://cr.openjdk.java.net/~twisti/6987555/webrev.02/
>>> 
>>> That works and seems to be a good patch.  It also adds a compiler test.
>> 
>> Looks good.  For consistency shouldn't methodHandles_x86.cpp use the same values?
> 
> It does.  vminfo is loaded from the method handle object and used to do the shifts.  methodHandles_sparc.cpp is actually not changed in this patch, it just contains some of John's cleanups.

Oh, right, I forgot how this works.  Looks good.

By the way, opt_i2i and opt_i2l are still unimplemented on sparc.  Is that on a list some where?

tom

> 
> -- Christian



More information about the hotspot-compiler-dev mailing list