RFR(S): JDK-8203481 Incorrect constraint for unextended_sp in frame:safe_for_sender

[David Holmes]

On 15/06/2018 7:02 AM, Daniel D. Daugherty wrote:
> On 6/14/18 9:44 AM, Andrew Haley wrote:
>> On 06/10/2018 10:05 PM, David Holmes wrote:
>>> I have to admit I still can't connect all the pieces here. When we are
>>> operating in frame::safe_for_sender, what has set _unextended_sp? Can
>>> you walk through a complete example? I can't quite connect Andrew's
>>> example to the original problem.
>>>
>>> It still seems to me that the current frame should have:
>>>
>>> sp <= unextended_sp <= stack_base()
>> No.  We save SP, then remove unused stack, then call int a method.
> 
> Where does this "remove unused stack" come from? And is that only
> an ARM thing? I don't remember seeing that on X64...

That's my confusion too. It seems to me this is being looked at from two 
different perspectives. I'm assuming that if we start with a given SP 
and then _add_ the extra stuff we get a new SP (logically an "extended 
SP" and the original SP is saved as the unextended_sp - and hence SP 
must be below unextended SP. But I have no real understanding of the 
mechanics here I'm just going off the description of unextended_sp.

David

> 
>> The address saved into the current method is the old SP, before stack
>> items were removed.  This is refereed to as the "unextended_sp" in th
>> eshared code, but it's actually *below* the SP when a method was
>> entered.
> 
> I can see how removing things from the stack (and incrementing SP) could
> result in an SP value > saved SP value. It's the "removing things from
> the stack" part that has me confused right now...
> 
> Also, we have a terminology problem in this thread. In this:
> 
>      sp <= unextended_sp <= stack_base()
> 
> I would say that 'sp' is below (or equal) to unextended_sp and that
> 'unextended_sp' is below (or equal) to stack_base(). To me "below"
> is like "less than" and "above" is like "greater than".
> 
> Dan