Question about JEP 270: Reserved Stack Areas for Critical Sections

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Mon May 2 11:05:31 UTC 2016


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.  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?



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.









More information about the hotspot-runtime-dev mailing list