276

It says here that -Xss is used to "set thread stack size", what does it mean exactly? Could anyone help me understand this?

naXa stands with Ukraine
  • 35,493
  • 19
  • 190
  • 259
instantsetsuna
  • 9,183
  • 8
  • 25
  • 28

5 Answers5

303

Each thread in a Java application has its own stack. The stack is used to hold return addresses, function/method call arguments, etc. So if a thread tends to process large structures via recursive algorithms, it may need a large stack for all those return addresses and such. With the Sun JVM, you can set that size via that parameter.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 15
    So, The -Xss option is used to limit how much memory a stack consumes (by storing return addresses, variables etc) and which also **indirectly** limits how deep a stack can get? Am I correct? – instantsetsuna Feb 11 '11 at 10:32
  • 6
    @instantsetsuna: I think the more common use is probably to *increase* the default limit. (There's always a limit.) But yes, you're controlling the size of the stack, which controls how deep the stack can get. – T.J. Crowder Feb 11 '11 at 10:34
  • how do you do the equivalent of this XSS setting on the java compiler (aka javac)? Its an issue for those who use scala-based libraries that cause large tail recursion to happen in the compilation of the classes – Andrew Norman 9 secs ago – Andrew Norman Apr 19 '18 at 21:15
  • @AndrewNorman: You don't compile Java runtime options into the class file, that's more an environment-specific thing. If you really need to do it in code, you can write a tiny main class whose sole job is to launch your real application with the options you need. – T.J. Crowder Apr 20 '18 at 06:59
  • 2
    @AndrewNorman You can give JVM configuration flags the compiler should run with using `-Jflag` syntax (eg. `-J-Xss`). – francoisr Jun 26 '18 at 08:48
  • @francoisr unfortunately the -J-Xss or -JXss does not work with SBT scripts. At least not with class compiling – Andrew Norman Jul 02 '18 at 22:04
  • @T.J.Crowder my issue is with SBT scripts not with compiled classes. Its the compiling of the classes that is the issue (not the running of the classes). Trying to find an inline setting that I can store in a repo rather than manually setting the XSS on every single build and dev machine. If you use Scala with Slick / shapeless persistence and big tables you'll hit this issue when you've described a table with 80-90 columns. This is because this library describes the tables with a compile-time tail recursion per defined column. – Andrew Norman Jul 02 '18 at 22:05
  • I talk more about my scenario in this thread. See my "workaround solution" -> https://stackoverflow.com/questions/19825809/out-of-memory-error-during-scala-compilation/49931558#49931558 – Andrew Norman Jul 02 '18 at 22:08
199

It indeed sets the stack size on a JVM.

You should touch it in either of these two situations:

  • StackOverflowError (the stack size is greater than the limit), increase the value
  • OutOfMemoryError: unable to create new native thread (too many threads, each thread has a large stack), decrease it.

The latter usually comes when your Xss is set too large - then you need to balance it (testing!)

Adam Adamaszek
  • 3,914
  • 1
  • 19
  • 24
  • 5
    Not necessarily every time actually. Both SOE and OOME could occur because of different reasons that should be fixed differently. – koders Jun 02 '15 at 21:24
  • 5
    True, but I didn't say -Xss is the only cause for SOE and OOME, but the other way round - if set incorrectly, it can cause one of the two. – Adam Adamaszek Jun 03 '15 at 13:48
8

Each thread has a stack which used for local variables and internal values. The stack size limits how deep your calls can be. Generally this is not something you need to change.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
5

If I am not mistaken, this is what tells the JVM how much successive calls it will accept before issuing a StackOverflowError. Not something you wish to change generally.

fd8s0
  • 1,897
  • 1
  • 15
  • 29
Kellindil
  • 4,523
  • 21
  • 20
1

Add my two cents here, besides what mentioned, we can write a simple demo to show the effect of setting Xss.

Generally speaking, it controls the stack size arranged to each thread.

    public static void main(String[] args) {
        try{
            recur();
        }catch (StackOverflowError e){
            System.out.println(depth);
        }
    }

    static int depth = 1;

    public static void recur(){
        depth++;
        recur();
    }

After compiling above code, you will see the depth (the invoke hierachy) grows together with the passed Xss settings.

The output of java -Xss1m com.eugene.Main is 21638 and the output of java -Xss2m com.eugene.Main is 48325 at my local machine.

Eugene
  • 10,627
  • 5
  • 49
  • 67