Can you retrieve your jvm's current stack size?

[Bob Ruth]

If this does not belong here, please pardon the mistake... I looked but could not figure out what the best place was so I just put it here.

We strongly suspect that our jvm is causing stack over-runs and we want to increase it as a test but I have seen much in conflicting information as to the real default thread stack size for our JVM 1.4.2. The startup scripts are not setting a stack size so we must be taking the default, just, I'm not sure what it is.

Does anyone know of a way to query the jvm on it's stack size?

Thanks,
Bob

[Henry Wong]

We strongly suspect that our jvm is causing stack over-runs and we want to increase it as a test but I have seen much in conflicting information as to the real default thread stack size for our JVM 1.4.2. The startup scripts are not setting a stack size so we must be taking the default, just, I'm not sure what it is.

There is no reason to "strongly suspect". If your stack is not big enough, you should be getting stack overflow errors. Check your logs, or your standard err.

Henry

[Bob Ruth]

THe reason I worded it that way is because we get a jvm crash dump that says unexpected signal 11 received which in Unix/Linux is a segment fault indicating that you ran off of mapped memory somewhere. It occurred way way down in libjvm.so which is in the bowels of the JVM itself. I found evidence on one of IBM's pages on Linux/Java that this exact footprint is one way that a stack overrun shows up. I dont know for certain but it seems reasonable that, if the JVM is executing the user's bytecode it may be able to catch a stack overrun before it happens and flag it properly. However, whe you are deep enough down in jvm code it may not be checking the stack every time the chip executes a subroutine call and if you are running that close to the edge it may make that call, start loading the stack, walk off the end of the mapped page and "kaboom" we have a segment fault.

Now, to the question, is there a way to find out dynamically what your current thread stack size is?

[Henry Wong]

If you are not doing JNI work, you should never get a segmentation violation. There is no "deep enough down in jvm code" that it "may not be checking the stack every time"... etc. A segmentation violation is a bug in the JVM, either upgrade your JVM, or report the bug to Sun or IBM.

You could speculate what is wrong -- but it is likely it is not even related to anything on the Java side of things.

Henry

[Bob Ruth]

Could I try this another way?
Lets pretend I never said anything about why I want to do this....

Is there a way to retrieve your current stack size setting from within a Java program?

[Henry Wong]

Could I try this another way?
Lets pretend I never said anything about why I want to do this....

Or maybe you can conclude that the reason why you are getting work-arounds, instead of a direct answer, is because there is no easy way to do this? (BTW, I am hoping to be wrong here)

Is there a way to retrieve your current stack size setting from within a Java program?

Oh right, let me take a shot at this... How about this? You could get the original arguments -- before the JVM process the flags from the JVM MBean server.

RuntimeMXBean rbean = ManagementFactory.getRuntimeMXBean();

List args = rbean.getInputArguments();

You can then iterate through the list, to see if the "-Xss" flag has been set. If it has, then great.

If it has not, then you need to assume the default. Unfortunately, the default is JVM specific -- you could get the system properties to determine what JVM and platform that you have, and use the defaults values for that config (which you have to google to get).

Henry