[Pljava-dev] Stack base pointer revisited

PL/Java is multi-threaded, and can use any thread to call back into the
backend. To avoid confusing the backend's stack-depth check, it sets the
stack_base_ptr whenever it calls a backend function. I think there are
two bugs in there:

First, when we set stack_base_ptr to the current stack pointer, we might
already have used up most of the stack, having only very little left.
However, the backend's stack check mechanism assumes that stack_base_ptr
is set roughly to the beginning of the stack, so that there is still
about max_stack_depth kilobytes of stack left.

That's what I thought, anyway. Googling around, I found some references
to a special "native stack", so perhaps the JVM creates a separate stack
for JNI calls. I tried to reproduce this with the attached class, which
recurses N times, where N is given as argument, and then runs a query.
When you install that as a PL/java function, and call rec(N) from a psql
session with different arguments, you get exciting results. If the
argument is small enough, it runs the query and returns a value
normally. If it's too large, you get a java.lang.StackOverflowError. But
if it's just right, the JVM crashes.

I'm not sure if this is a JVM bug, or if we should be doing a stack
depth check somewhere in the JNI functions, or if this is because we set
stack_base_ptr incorrectly.

The second bug is that on Itanium, there are actually two stacks. One
"regular" stack, and another for pushing registers. The backend stack
depth code checks and has a separate base pointer for both, but PL/java
only saves/restores the regular stack's base pointer.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PLJavaTest.java
Type: text/x-java
Size: 555 bytes
Desc: not available
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20120328/b63cbb30/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid9027.log
Type: text/x-log
Size: 708541 bytes
Desc: not available
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20120328/b63cbb30/attachment-0001.bin>