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

Christian Thalinger christian.thalinger at oracle.com
Tue Oct 12 10:07:03 PDT 2010


On 10/12/10 7:01 PM, Tom Rodriguez wrote:
>
> 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?

Not really, I just never ran a test that used it.  I will try tomorrow 
to write something and implement it.

Thanks for the review!

-- Christian


More information about the hotspot-compiler-dev mailing list