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

[Christian Thalinger]

On Fri, 2010-04-09 at 09:34 -0700, Vladimir Kozlov wrote:
> On 4/9/10 8:13 AM, Christian Thalinger wrote:
> >>
> >> MethodHandles::generate_method_handle_interpreter_entry():
> >>
> >> !     Register tem = G5_method;
> >> !     for (jint* pchase = methodOopDesc::method_type_offsets_chain(); (*pchase) != -1; pchase++) {
> >> !       __ ld_ptr(tem, *pchase, G5_method_type);
> >> !       tem = G5_method_type;       // yes, it's the same register...
> >>               ^ it is loop invariant, why you put it inside?
> >> !     }
> >
> > I'm not sure I understand.  G5_method_type is loaded in the ld-ptr
> > instruction from Address(tem, *pchase).
> 
> tem = G5_method_type is register renaming - it is not moving value,
> so you don't need to do renaming inside loop.

Ahh, got it.  That is because of the porting from x86.  I removed the
code from the loop and added an assert.

> >>
> >> Also MacroAssembler::load_method_handle_vmslots() has next code which
> >> looks similar to above but has the check "!= 0"
> >>
> >> !   if (java_dyn_MethodHandle::vmslots_offset_in_bytes() != 0) {
> >> !     // hoist vmslots into every mh to avoid dependent load chain
> >> !     ld(    Address(mh_reg,    delayed_value(java_dyn_MethodHandle::vmslots_offset_in_bytes, temp_reg)),   vmslots_reg);
> >> !   } else {
> >> !     Register temp2_reg = vmslots_reg;
> >> !     ld_ptr(Address(mh_reg,    delayed_value(java_dyn_MethodHandle::type_offset_in_bytes, temp_reg)),      temp2_reg);
> >> !     ld_ptr(Address(temp2_reg, delayed_value(java_dyn_MethodType::form_offset_in_bytes, temp_reg)),        temp2_reg);
> >> !     ld(    Address(temp2_reg, delayed_value(java_dyn_MethodTypeForm::vmslots_offset_in_bytes, temp_reg)), vmslots_reg);
> >> !   }
> >
> > You want me to reuse that code?
> 
> No. I was confused that in load_method_handle_vmslots() there is separate code when vmslots_offset_in_bytes() != 0 and 
> generate_method_handle_interpreter_entry() does not have such code.

Hmm.  I don't know the details here (John should) but maybe that's
because we dig out the right MethodType and then retrieve the vmslots value from
that MethodType and the short-cut is not valid at that point.  But
that's just a guess.

Here is the updated webrev:

http://cr.openjdk.java.net/~twisti/6829193/webrev.03/

-- Christian