Request for reviews (XL): 6829193: JSR 292 needs to support SPARC
Christian.Thalinger at Sun.COM
Fri Apr 23 05:11:29 PDT 2010
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.
More information about the hotspot-compiler-dev