RFR(S): 8156992: [ppc] Implement template interpreter stack overflow checks as on x86/sparc.

[Lindenmaier, Goetz]

Hi Dean,

I'll reply with the correct bugID.

Best regards, and sorry for this confusion,
  Goetz.

From: dean.long at oracle.com [mailto:dean.long at oracle.com]
Sent: Thursday, May 19, 2016 7:14 PM
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(S): 8156992: [ppc] Implement template interpreter stack overflow checks as on x86/sparc.

Hi Goetz.  Thanks for the explanation.  So using the shadow size in MAX2 is so that the
stack bang that comes next does not "overshoot" the red zone and stomp on memory
that might be mapped for other purposes?  That makes sense if bang_stack_shadow_pages()
was only banging one page, but when called from generate_normal_entry(), "native_call" is
set to false, so we bang from 1 to n_shadow_pages.  If I'm now understanding the code
correctly, there may be an opportunity for a performance improvement here, by banging
just 1 page instead of n_shadow_pages.

I reread the description in 8156922, and I'm having troubling following the note that
starts with "The x86/sparc design can not handle frames bigger than ...."  Is the that
"overshoot" problem I described above?


thanks,

dl

On 5/19/16 6:38 AM, Lindenmaier, Goetz wrote:
Hi,

reading the mail again I think I understand your question better now:

I think this is because we first want to push the frame of the called method
and then do the real stack bang.
But at least it must be checked that this frame fits on the stack below the yellow zone.
Obviously the person who implemented this also wanted to make sure that a
stack bang on top of this frame does not exceed stack_end(), therefore the MAX2.
If it does not fit, a stack overflow error is thrown without going through the
signal handler - only the space of the shadow zone is used.

If the frame fits, the real stack bang is executed. The frames below are all fine, thus
the signal handler and code on top can walk the stack.

Best regards,
  Goetz.



From: dean.long at oracle.com<mailto:dean.long at oracle.com> [mailto:dean.long at oracle.com]
Sent: Thursday, May 19, 2016 2:15 AM
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com><mailto:goetz.lindenmaier at sap.com>; hotspot-runtime-dev at openjdk.java.net<mailto:hotspot-runtime-dev at openjdk.java.net>
Subject: Re: RFR(S): 8156992: [ppc] Implement template interpreter stack overflow checks as on x86/sparc.

By changing the value of the _stack_overflow_limit field, does the following x86/sparc comment
still make sense?

// TODO: rather than touching all pages, check against stack_overflow_limit and bang yellow page to
// generate exception

Also, I have to admit that I don't understand why we use different values for stack checks/bang in different places, especially the using MAX2 instead of +.  Can anyone explain this?  The + makes sense to me, but the MAX2 does not.

dl
On 5/18/16 3:02 AM, Lindenmaier, Goetz wrote:

Hi,







When porting the template interpreter, we implemented a different approach to



Stack overflow handling.  See also the detailed description in the Jira bug.







This change implements the stack overflow check as on x86/sparc.



It requires simple shared changes, but only to code only used on ppc.



The changes should not affect the other platforms.







Please review this change. I please need a sponsor.



http://cr.openjdk.java.net/~goetz/wr16/8156922-ppcStackFix/webrev.01/<http://cr.openjdk.java.net/%7Egoetz/wr16/8156922-ppcStackFix/webrev.01/>







Best regards,



  Goetz.