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