Request for reviews (XL): 6829193: JSR 292 needs to support SPARC

Tom Rodriguez tom.rodriguez at oracle.com
Tue Apr 27 11:04:46 PDT 2010


By the way, I noticed that you had an assert !UseCompressedOops in some of the code.  You should be able to support it appropriately by simply using load_heap_oop instead of ld_ptr.  The basic rule is use load_heap_oop if the field is a compressed oop, which applies to all normal Java fields, and use ld_ptr if the field is actually declared in C++, like the special oop fields in Thread.  There are some corner cases but that gets you through most of them.

tom

On Apr 27, 2010, at 4:47 AM, Christian Thalinger wrote:

> On Mon, 2010-04-26 at 12:04 -0700, Tom Rodriguez wrote:
>> On Apr 26, 2010, at 7:49 AM, Christian Thalinger wrote:
>> 
>>> On Fri, 2010-04-23 at 15:46 -0700, John Rose wrote:
>>>> On Apr 23, 2010, at 10:22 AM, Tom Rodriguez wrote:
>>>> 
>>>>>> 
>>>>>> void regcon_sll_ptr(RegisterOrConstant s1, RegisterOrConstant s2, RegisterOrConstant d);
>>>>> 
>>>>> I'd be ok with that for sparc, though I think you still need the
>>>> temp if dest and src were both constants that were larger than a
>>>> simm13.
>>> 
>>> Yes, a temp is required.  I missed that above.
>>> 
>>>> 
>>>> *And* the destination value has to be passed by-reference, because if
>>>> the temp is used for materialization, the updated destination will
>>>> have to be passed back out to the caller.
>>> 
>>> Right.  Here is the change:
>>> 
>>> http://cr.openjdk.java.net/~twisti/6829193/webrev.05/
>>> 
>>> I like that much more.
>> 
>> It's better but I still don't like the value return parameter.  Almost
>> every path through there changes the value of dest and that seems like
>> something that should be directly returned.  If it always produced its
>> result in a register then I think it should follow the pattern of
>> sll_ptr but since it doesn't I think it should follow a different
>> pattern.
> 
> Last try :-)
> 
> http://cr.openjdk.java.net/~twisti/6829193/webrev.06/
> 
> -- Christian
> 



More information about the hotspot-compiler-dev mailing list