stack frames

[Tom Rodriguez]

On Aug 14, 2009, at 4:51 PM, Hiroshi Yamauchi wrote:

> Hi Tom,
>
> For C1, I found a picture in c1_FrameMap.hpp:
>
> //   stack grow direction -->
> SP
> //  +----------+---+----------+-------+------------------------+-----+
> //  |arguments | x | monitors | spill | reserved argument area | ABI |
> //  +----------+---+----------+-------+------------------------+-----+
> //
> //  x =  ABI area (SPARC) or  return adress and link (i486)
> //  ABI  = ABI area (SPARC) or nothing (i486)
>
> Is that basically the same as what you described for C2 frames (i.e.
> do C1 and C2 have the same stack frame layout after all)?

They are pretty much the same.  You can have c1 and c2 generated  
frames on the stack in the same jvm and we don't have to treat them  
any differently.

> On x86, are the arguments passed via stack like the C calling
> convention (and how about floating point values)?

The calling convention logic is in  
SharedRuntime::java_calling_convention and c1 and c2 use the same  
calling convention.  On 32-bit x86, we pass the first 2 int/oop  
arguments in ecx and edx and up to 2 FP arguments in SSE registers  
with the rest on the stack.

>
> Does a C2 frame have 'sender sp' as frame_x86.hpp says:
>
> public:
>  enum {
>    pc_return_offset                                 =  0,
>    // All frames
>    link_offset                                      =  0,
>    return_addr_offset                               =  1,
>    // non-interpreter frames
>    sender_sp_offset                                 =  2,

The sender_sp offset is always the value of the callers ebp but with  
C2 ebp is an allocatable register.  Stack walking should be done by  
asking the nmethod for it's frame_size and subtracting that from the  
current sp.  We don't use sender_sp for stack walking compiled frames  
at all.

> or is it cruft?
>
> Also, if 'adapter frames' exist (eg from compiled -> interpreted and
> vice versa), what do they look like?

As of 1.6 there are no adapter frames.  We do have chunks of code for  
adapting calling conventions but they are required to operate as  
trampolines.  There's a little bit of magic as well having to do with  
enlarging the callers frame to make space for stack arguments.

tom

>
> Thanks,
> Hiroshi
>
> On Fri, Aug 14, 2009 at 3:49 PM, Tom Rodriguez<Thomas.Rodriguez at sun.com 
> > wrote:
>> I don't know that there's a specification of compiled frames  
>> anywhere.  We
>> generally use standard call and return sequences and construct our  
>> frames
>> following the platform ABI, though on x86 we don't maintain ebp as  
>> the frame
>> pointer but treat it as callee saved and store it in the standard  
>> place and
>> use no other callee saved registers.  The frame contains monitor  
>> records,
>> spill slots and the outgoing argument area in that order.  I think  
>> that's
>> about the extent of what's specified.  matcher.cpp contains all the  
>> frame
>> layout logic for c2.
>>
>> tom
>>
>> On Aug 14, 2009, at 1:48 PM, Chuck Rasbold wrote:
>>
>>> A colleague asked me for a specification of HotSpot (actually, C2)  
>>> stack
>>> frames.
>>>
>>> My JVM skills are a little rusty, and I realize that my knowledge  
>>> is based
>>> more on experience, rather than a spec.
>>>
>>> Where are the most authoritative descriptions of the frame layout in
>>> HotSpot?  Even if there is not one in the code, is there one in  
>>> John Rose's
>>> HotSpot internals wiki?
>>>
>>> -- Chuck
>>
>>