Question about JEP 270: Reserved Stack Areas for Critical Sections

[Frederic Parain]

On 02/05/2016 13:05, Lindenmaier, Goetz wrote:
> Hi Frederic,
>
> 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