[aarch64-port-dev ] Code for frame setup is a bit ... odd?

[Andrew Dinn]

On 22/11/13 12:28, Andrew Dinn wrote:
> On 22/11/13 11:57, Andrew Haley wrote:
>> Note that we're creating a stackframe of 16 bytes that isn't used.  I wonder
>> what's going on here.  x86 seems to do the same thing:
> 
> There is a reason for this, documented deep in the depths of the stub
> code but I cannot recall exactly where (arch specific stubGenerator
> code???). I think it is because something needs a scratch stack area.
> I'll take a look and post when I find it.

The culprit is Compiler::Compile() -- the one which compiles a method
rather than a stub. It ensures that C->frame_slots() is always positive
because it adds an extra slot to the frame for use by deopt code:

compile.cpp:856

  // Now that we know the size of all the monitors we can add a fixed slot
  // for the original deopt pc.

  _orig_pc_slot =  fixed_slots();
  int next_slot = _orig_pc_slot + (sizeof(address) /
VMRegImpl::stack_slot_size);
  set_fixed_slots(next_slot);

This percolates into the definition of Matcher::compute_old_SP
(matcher.cpp) where it is rounded up from 0x8 to 0x10 and, in turn, this
gets used to compute the value of _frame_slots (compile.cpp again). So,
_frame_slots is always a minimum of 0x20 which, even after removing the
0x10 for in_preserve_slots (pushed FP and LR) always leaves a positive
frame size.

regards,


Andrew Dinn
-----------