pts pts - 10 days ago 7
Java Question

How to increase the Java stack size?

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.

Answer

Hmm... it works for me and with far less than 999MB of stack:

> java -Xss4m Test
0

(Windows JDK 7, build 17.0-b05 client VM, and Linux JDK 6 - same version information as you posted)