JNI stack size issues

[Fletcher Curry]

My application, written in BASIC and C, creates a Java Virtual Machine with JNI_CreateJavaVM, then periodically makes calls to a Java method. Between these calls, it allocates a lot of memory on the stack, which I think is giving the JVM trouble. My process aborts with this message:

Assertion failed: sp >= ((char*) (t->stackbase)) - MAX_STACK_SIZE, file JDEV:[fastvm.srcjava.sys.alpha]gcinit.c;4, line 464

I have tried increasing Java's stack size with both -Xss and -XX:MainThreadStackSize. -Xss resulted in OutOfMemoryErrors. -XX:MainThreadStackSize had no noticeable effect. Any ideas about what's going on here? I'm using Java 1.5.0 on VMS 7.3-2.

Thanks.

- Fletcher

[Rick Retterer]

Fletcher,
I believe we used to see this error back in Java 1.3.1-x, I'll have to dig through my older correspondence to get the particulars on it.

In the meantime, can you define what you mean by "it allocates a lot of memory on the stack"? What is "a lot of memory"?

Is the problem reproducable at will?

Have you tested your code with Java 1.4.2-x and did you see the same failures that you are seeing with 1.5?

In addition, what values are you using with the -Xss#### arguments on the java command-line?

Cheers,
Rick Retterer
HP Services
OpenVMS, Tru64 Java Support

[Fletcher Curry]

Rick -

It turns out that my assertion that the application "allocates a lot of memory on the stack" is false. The highest stack usage I spotted after I create the JVM is only about 75K more than when it was created. Some specifics:
SP when I create the JVM: 2060787104
SP when I call the java method: 2060790288
min observed subsequent SP: 2060707616
max observed subsequent SP: 2061100112

The problem is reproducable, in that it occurs in every process that calls this function. It doesn't always show up at the same spot, though. Sometimes I can make several calls before it occurs, sometimes it happens after just one. Sometimes it occurs when the process is active, sometimes when it is waiting for input from the terminal. I'm guessing this variability is because it happens when the garbage collector runs.

I have not tested this with Java 1.4.2, but I will try to do so. This is complicated by the fact that my method uses RMI classes that were compiled on a Windows machine running 1.5.0. In the past I've had trouble using classes compiled by a higher version of java.

When I use -Xss2m the problem still occurs, though it does seem to take longer. Wnen I use -Xss10m, I get this when I call the java method:
Exception in thread "SeedGenerator Thread" java.lang.OutOfMemoryError
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:574)
at sun.security.provider.SeedGenerator$ThreadedSeedGenerator.run(SeedGenerator.java:282)
at java.lang.Thread.run(Thread.java:595)
pool_alloc: out of memory, file JDEV:[fastvm.srcjava.util]pool.c;1, line 117
util_malloc: out of memory, file JDEV:[fastvm.srcjava.runtime]port.c;2, line 110

Thanks.

- Fletcher

[Fletcher Curry]

These stack usage numbers made me realize that it's not actually a matter of my stack usage after I create the JVM, but my stack usage beforehand. If I invoke the garbage collector from my java method, it fails on the first call. Once I had come to this realization, I was able to write a simple example that demonstrates this behavior. Source code for this example is in the attached JAR. The COM file compiles, links, and runs the program.

This program behaves the same under Java 1.4.2-3, 1.5.0-beta1, and 1.5.0-1. Using the Fast VM, it fails when the garbage collector runs. Using the Classic VM, it works fine. This would seem to suggest a workaround: use the Classic VM. Unfortunately, I have other code that fails with the Classic VM and only works with the Fast VM, so this is not an option.

Thanks.

- Fletcher

[Rick Retterer]

Fletcher,

I have copied down the jar file, let me have a look at it and I'll get back to you on it. I'm swamped at the moment, but I'll try to stay a little late and work on it for you.

Thanks for putting it together, I was going to ask you if you had someway to reproduce the problem. You read my mind.

Cheers,
Rick

[Rick Retterer · Accepted solution]

Fletcher,
It's a bug in in Java for OpenVMS 1.4.2-x and 1.5-x.

It seems that the gcinit.c code limits the Stack Space for OpenVMS to only 1mb, while the Unix side of the assignments was setup for 1gb.

Java engineering is aware of the problem, and will be fixing it in a upcoming release.

To workaround the problem, you will need to create another thread to run your JVM stuff under.

You will need to log a call to HP Support with the OpenVMS java team (Attention Rick Retterer Java Support) to officially report the problem and to receive a patched version of Java until the fix makes it into the next release available to the public.

Sorry that you ran into this, it looks like it was an oversite that needs to be addressed by engineering.

Cheers,
Rick Retterer
HP Services
Java Support
Atlanta, GA.

[Fletcher Curry]

Rick -

Thanks for your help. I have some other processes aborting with the message:

Assertion failed: s->exc != NULL, file JDEV:[fastvm.srcjava.sys.alpha]einfo_vms.c;7, line 349

Is it likely that this is another manifestation of the same problem?

- Fletcher