Request for reviews (M): 6930772: JSR 292 needs to support SPARC C1

[Tom Rodriguez]

On Apr 16, 2010, at 2:48 PM, John Rose wrote:

> I like it too; reviewed.
> 
> The use of L0 is tricky.  You call it L7 in one comment.  Be sure that all of these uses of L0 are linked together by comments.
> 
> The change touches one of my pet peeves:  The SP adjustment tracking in the frame logic has always seemed awkward to me (not from your change).  I don't see a clearer reformulation yet.  (Chuck Rasbold made it better with the unextended_sp stuff.)
> 
> One partial cleanup would lead to some simplifications.  It would change the convention by which the interpreter pops its outgoing arguments.  Currently it pretends to keep the arguments on stack throughout the call; it should release them to the callee before completing the control transfer to the callee.

I'm not sure how this can be changed.  The outgoing expression stack forms the base of the locals in the callee frame.  The SP of the frame also has to cover all live values in the frame throughout its lifetime, otherwise a signal handler frame can be pushed on top of the current SP and overwrite live values.  It's also possible to stop at the call site and GC before entering the callee and the arguments have to be live somewhere when this occurs.  Also on sparc Lesp and SP are different registers but on intel they are the same which can complicate any changes in this area.  Am I misunderstanding what you are suggesting needs to be changed?

>  Currently, as a result, a return to the interpreter resets to a saved SP that points to the argument list base (lowest address, not highest), the address of an argument list that (at that point) is long gone.  The interpreter must then perform extra calculations to re-adjust the SP by the size of the absent argument list, calculations which add no value.  And when stack walking, we have to continually remember that the unextended SP might overlap with stack storage owned by the callee, which is counterintuitive and therefore bug-prone.

That's new with method handles.  Previously frames could only be enlarged as a result of SP adjustments by the callee but the new argument shuffling logic means they can be shrunk too.  The shrinking could be avoided if we moved all the arguments when shrinking was required.  Again I don't see how this can be avoided unless you disallow frame size adjustment which is pretty much impossible I think.

tom

> 
> -- John
> 
> On Apr 16, 2010, at 5:41 AM, Christian Thalinger wrote:
> 
>> On Thu, 2010-04-15 at 10:31 -0700, Tom Rodriguez wrote:
>>> Could the is_method_handle_invoke become part of CodeEmitInfo instead?
>>> That would make more sense to me.
>> 
>> Right.  This looks much better:
>> 
>> http://cr.openjdk.java.net/~twisti/6930772/webrev.03/
>> 
>> -- Christian
>> 
>