Question about JEP 270: Reserved Stack Areas for Critical Sections

[Lindenmaier, Goetz]

Hi Frederic,

> What do you mean by "no effect"?
The normal entry does two stack checks. 
It first does a compare. It compares SP against stack_end + (red+yellow+reserved)
(or stack_end + shadow).
See templateInterpreterGenerater_x86.cpp:521
It loads stack_base and stack_size, and computes the value to compare against.
This first check is what I meant. It's independent of whether the zones are protected
or not.

I now see that further down in normal_entry, there is the normal stack bang, too.
I missed that before.

Also I figured that x86/sparc use the max of shadow / guard zone for the compare.
So the bang further down actually does more than the compare.
  MAX2(JavaThread::stack_shadow_zone_size(),
                JavaThread::stack_guard_zone_size());

This is different on ppc, there we compare against the sum, and then skip
the stack bang.  I'll check whether it works if I fix that.


But why are there two stack overflow checks?


> The important method is not setExclusiveOwnerThread() but the
> enclosing lock() method. In JDK code, the annotated method is
> lock():
I understand that if, for example Thread.currentThread() gets a stack 
overflow, you want the code to finish, i.e., you want to gain space to 
push setExclusiveOwnerThread() on the stack.

Best regards,
  Goetz.


> > I'm currently porting JEP 270 to PPC.
> > Now I ran into an issue I don't understand, or where I think it's wrong.
> > I've been looking at the test that comes with the change.
> > I understand the test shall cause a stack overflow where one of the
> > Methods annotated with @ReservedStackAccess
> > is on the stack.
> > In this case, the ReservedZone is unprotected, and further Java code
> > Is executed.
> > As I understand, unprotecting the ReservedZone has no effect for
> > code running interpreted.
> 
> What do you mean by "no effect"?
> Unprotecting the ReservedZone allows the method to continue its
> execution instead of receiving a SOE.
> 
> >  The size of the protected zones is hard-coded
> > into the interpreter(see templateInterpreterGenerator_x86.cpp)
> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e286c9ccd58d
> > So how can setExclusiveOwnerThread() benefit from the
> > gained space on the stack if it's running interpreter?
> 
> The important method is not setExclusiveOwnerThread() but the
> enclosing lock() method. In JDK code, the annotated method is
> lock():
> 
>          @ReservedStackAccess
>          final void lock() {
>              if (compareAndSetState(0, 1))
>                  setExclusiveOwnerThread(Thread.currentThread());
>              else
>                  acquire(1);
>          }
> 
> 
> The goal of the ReservedZone is to allow annotated methods to
> complete their execution without receiving a SOE.
> 
> Most of the time, the ReservedZone behaves like the YellowZone:
> if the zone is hit, the a SOE is thrown immediately.
> 
> But if the ReservedZone is hit AND there's an annotated method
> on the stack, then the ReservedZone is unprotected and can be
> used as regular stack space, as long as there's at least one
> annotated method on the stack. In the case of the lock()
> method, all methods inside its body (compareAndSetState(),
> setExclusiveOwnerThread(), currentThread(), acquire()), and
> recursively all methods called by these methods, will have
> access to the unprotected ReservedZone. The fact that the
> methods are compiled or interpreted doesn't matter.
> 
> The fact that the test excludes setExclusiveOwnerThread() from
> being compiled is just an artifact to reproduce the scenario
> where a stack overflow can occur on the line:
>                  setExclusiveOwnerThread(Thread.currentThread());
> The initial scenario of the bug was too hard to reproduce so
> I've used this trick.
> 
> Regards,
> 
> Fred
> 
> > On ppc, we load the limit to compare the SP against from the
> > Thread. With this design, we could easily give the interpreter
> > the possibility to use the unprotected space by resetting that
> > boundary when we protect/unprotect a zone.
> >
> > Best regards,
> >
> >    Goetz.
> >
> 
> --
> Frederic Parain - Oracle
> Grenoble Engineering Center - France
> Phone: +33 4 76 18 81 17
> Email: Frederic.Parain at oracle.com