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

[Christian Thalinger]

On Wed, 2010-04-21 at 11:13 -0700, Tom Rodriguez wrote:
> Resending to list because it bounced.
> 
> This change:
> 
> +  void get_cache_entry_pointer_at_bcp(Register cache, Register tmp, int bcp_offset, bool giant_index = false);
> 
> seems spurious.

I think John has a patch out that changes that.

> 
> I think the return_entry_for changes aren't really in the spirit of
> the design of the template interpreter.  If invokedynamic has it's own
> strategy for lookup in the constant pool then it probably needs it's
> own return entry point.  The invokedynamic case would select a new
> table in prepare_invoke that was generated by a call to
> generate_return_entry_for with a new flag indicating that the bytecode
> being handled is invokedynamic so it could use the giant cp cache
> logic.  What you've got is ok but it's not really the way the template
> interpreter works.
> 
> regcon_sll_ptr_by_con sure is convenient but its implementation is
> totally surprising and the name is long and unclear particularly since
> it has the same signature as regcon_sll_ptr but does something
> different.  It desperately needs a comment in the hpp explaining what
> it does.  I don't think dst should ever be optional, otherwise why it
> at all.  This use:
> 
> +      __ add(Gargs, __ regcon_sll_ptr_by_con(G5_stack_move, LogBytesPerWord, G5_stack_move), Gargs);
> 
> should just be sll_ptr.  

I changed that.

> Actually given all the magic that the existing regcon_sll_ptr does,
> couldn't you shoehorn the new behaviour into it?  The by_con behaviour
> of returning the new regcon instead of the value return parameter
> seems better anyway.

Working on that.

-- Christian