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 . Eg 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 eg 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.

    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)

    I assume you calculated the "depth of 1024" by the recurring lines in the stack trace?

    Obviously, the stack trace array length in Throwable seems to be limited to 1024. Try the following program: 

    public class Test {

    public static void main(String[] args) {

        try {
            System.out.println(fact(1 << 15));
        }
        catch (StackOverflowError e) {
            System.err.println("true recursion level was " + level);
            System.err.println("reported recursion level was " +
                               e.getStackTrace().length);
        }
    }

    private static int level = 0;
    public static long fact(int n) {
        level++;
        return n < 2 ? n : n * fact(n - 1);
    }
}

    If you want to play with the thread stack size, you'll want to look at the -Xss option on the Hotspot JVM. It may be something different on non Hotspot VM's since the -X parameters to the JVM are distribution specific, IIRC.

    On Hotspot, this looks like java -Xss16M if you want to make the size 16 megs.

    Type java -X -help if you want to see all of the distribution specific JVM parameters you can pass in. I am not sure if this works the same on other JVMs, but it prints all of Hotspot specific parameters.

    For what it's worth - I would recommend limiting your use of recursive methods in Java. It's not too great at optimizing them - for one the JVM doesn't support tail recursion (see Does the JVM prevent tail call optimizations?). Try refactoring your factorial code above to use a while loop instead of recursive method calls.

    链接地址: http://www.djcxy.com/p/80296.html

    上一篇: 关于在多线程环境中捕获SIGSEGV

    下一篇: 如何增加Java堆栈大小？