stack frames

[Hiroshi Yamauchi]

Tom, Thanks a lot as always. That is very helpful.

On Fri, Aug 14, 2009 at 5:30 PM, Tom Rodriguez<Thomas.Rodriguez at sun.com> wrote:
>
> 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
>>>
>>>
>
>