I asked this question to get to know how to increase the runtime call stack size in the JVM. I've got an answer to this, and I've also got many useful answers and comments relevant to how Java handles the situation where a large runtime stack is needed. I've extended my question with the summary of the responses.
Originally I wanted to increase the JVM stack size so programs like runs without a StackOverflowError.
public class TT {
public static long fact(int n) {
return n < 2 ? 1 : n * fact(n - 1);
}
public static void main(String[] args) {
System.out.println(fact(1 << 15));
}
}
The corresponding configuration setting is the java -Xss... command-line flag with a large enough value. For the program TT above, it works like this with OpenJDK's JVM:
$ javac TT.java
$ java -Xss4m TT
One of the answers has also pointed out that the -X... flags are implementation dependent. I was using
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-0ubuntu1~8.04.3)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)
It is also possible to specify a large stack only for one thread (see in one of the answers how). This is recommended over java -Xss... to avoid wasting memory for threads that don't need it.
I was curious how large a stack the program above exactly needs, so I've run it n increased:
- -Xss4m can be enough for
fact(1 << 15) - -Xss5m can be enough for
fact(1 << 17) - -Xss7m can be enough for
fact(1 << 18) - -Xss9m can be enough for
fact(1 << 19) - -Xss18m can be enough for
fact(1 << 20) - -Xss35m can be enough for
fact(1 << 21) - -Xss68m can be enough for
fact(1 << 22) - -Xss129m can be enough for
fact(1 << 23) - -Xss258m can be enough for
fact(1 << 24) - -Xss515m can be enough for
fact(1 << 25)
From the numbers above it seems that Java is using about 16 bytes per stack frame for the function above, which is reasonable.
The enumeration above contains can be enough instead of is enough, because the stack requirement is not deterministic: running it multiple times with the same source file and the same -Xss... sometimes succeeds and sometimes yields a StackOverflowError. E.g. for 1 << 20, -Xss18m was enough in 7 runs out of 10, and -Xss19m wasn't always enough either, but -Xss20m was enough (in all 100 runs out of 100). Does garbage collection, the JIT kicking in, or something else cause this nondeterministic behavior?
The stack trace printed at a StackOverflowError (and possibly at other exceptions as well) shows only the most recent 1024 elements of the runtime stack. An answer below demonstrates how to count the exact depth reached (which might be a lot larger than 1024).
Many people who responded has pointed out that it is a good and safe coding practice to consider alternative, less stack-hungry implementations of the same algorithm. In general, it is possible to convert to a set of recursive functions to iterative functions (using a e.g. Stack object, which gets populated on the heap instead of on the runtime stack). For this particular fact function, it is quite easy to convert it. My iterative version would look like:
public class TTIterative {
public static long fact(int n) {
if (n < 2) return 1;
if (n > 65) return 0; // Enough powers of 2 in the product to make it (long)0.
long f = 2;
for (int i = 3; i <= n; ++i) {
f *= i;
}
return f;
}
public static void main(String[] args) {
System.out.println(fact(1 << 15));
}
}
FYI, as the iterative solution above shows it, the fact function cannot compute the exact factorial of numbers above 65 (actually, even above 20), because the Java built-in type long would overflow. Refactoring fact so it would return a BigInteger instead of long would yield exact results for large inputs as well.
StackOverFlow, programmers not. – Fragmentary