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

[John Rose]

On Apr 19, 2010, at 3:54 AM, Christian Thalinger wrote:

> L0?  I think you mean L7.  I only use L0 in unwind_exception to store a
> temporary result.

Yes, I meant L7.  (I was looking at L0 used as a temp. nearby in c1_Runtime1_sparc.cpp.)

The places where C1 uses L7 to correct the stack need to be clearly linked, perhaps by a shared symbolic constant.

I see these places:
 - method_handle_invoke_SP_save_opr in c1_FrameMap_sparc.hpp
 - the tricky restore of L7 to SP in c1_Runtime1_sparc.cpp
 - the use of L7 to correct sp_adjustment_by_callee in frame_sparc.cpp

The shared symbolic constant could be method_handle_invoke_SP_save_opr itself, if there's a way of digging L7 out of it.

The basic rule here is the each type of frame that makes method handle invokes must preserve SP across those invokes.

The interpreter already does so, stashing SP in the last_sp stack frame variable on all platforms.

On Intel, both compilers (C1 and C2) stash SP in RBP.  On SPARC they both use L7.

When walking the stack, the preserved SP has to be taken into account.  For the interpreter this is based on the last_sp variable, which is accessed via the frame pointer.  For compiled code, which doesn't necessarily have frame pointers, the stack walker has to (a) determine if the call was a MH invoke, and (b) if so pull the corrected stack pointer out of a preserved register.

Is that all correct?  If so, the story (and what charming one it is :-) should be put into comments somewhere, perhaps near the shared symbolic constant for the preserved register.

-- John