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