Comment augmenter la taille de la pile Java?

je suppose que vous avez calculé la "profondeur de 1024" par les lignes récurrentes dans la trace de la pile?

de toute évidence, la longueur du réseau de traces de pile dans Throwable semble être limitée à 1024. Essayez le programme suivant:

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);
    }
}

si vous voulez jouer avec la taille de la pile de threads, vous voudrez regarder l'option-Xss sur le Hotspot JVM. Il peut être quelque chose de différent sur les VM Non Hotspot puisque les paramètres-X de la JVM sont spécifiques à la distribution, IIRC.

sur Hotspot, ça ressemble à java -Xss16M si vous voulez faire la taille 16 megs.

Type java -X -help si vous voulez voir tous les paramètres JVM spécifiques à la distribution, vous pouvez passer. Je ne suis pas sûr si cela fonctionne de la même façon pour les autres JVM, mais il imprime tous les paramètres spécifiques des points chauds.

pour ce que ça vaut - je recommande de limiter votre utilisation de méthodes récursives en Java. Il n'est pas très efficace de les optimiser, car la JVM ne supporte pas la recursion de queue (voir ). la JVM empêche-t-elle les optimisations d'appel de queue? ). Essayez de refactoriser votre code factoriel ci-dessus pour utiliser une boucle while au lieu d'appels de méthode récursifs.

la seule façon de contrôler la taille de la pile dans le processus est de lancer un nouveau Thread . Mais vous pouvez également contrôler en créant un processus sub Java auto-appelant avec le paramètre -Xss .

public class TT {
    private static int level = 0;

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

    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(null, null, "TT", 1000000) {
            @Override
            public void run() {
                try {
                    level = 0;
                    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);
                }
            }

        };
        t.start();
        t.join();
        try {
            level = 0;
            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);
        }
    }

}

ajouter cette option ""

--driver-java-options -Xss512m

à votre commande spark-submit corrigera ce problème.

il est difficile de donner une solution raisonnable puisque vous êtes désireux d'éviter toutes les approches saines. Refactoring une ligne de code est la senible solution.

Note: utiliser-Xss définit la taille de la pile de chaque thread et est une très mauvaise idée.

une autre approche consiste à modifier le code octet comme suit:

public static long fact(int n) { 
    return n < 2 ? n : n > 127 ? 0 : n * fact(n - 1); 
}

donné chaque réponse pour n > 127 est 0. Cela évite de changer le code source.

Bizarre! Vous dites que vous voulez générer une recursion de 1<<15 profondeur ???!!!!

je vous conseille de ne pas essayer. La taille de la pile sera 2^15 * sizeof(stack-frame) . Je ne sais pas ce qu'est la taille de la pile, mais 2^15 est 32.768. A peu près... Eh bien, si elle s'arrête à 1024 (2^10) vous aurez à faire 2^5 fois plus grand, il est, 32 fois plus grand qu'avec votre réglage réel.

D'autres affiches ont montré comment augmenter la mémoire et qu'on pouvait mémoriser les appels. Je suggère que pour de nombreuses applications, vous pouvez utiliser la formule de Stirling pour se rapprocher du grand n! très rapidement avec presque aucune empreinte mémoire.

jetez un coup d'oeil à ce poste, qui a une certaine analyse de la fonction et du code:

http://threebrothers.org/brendan/blog/stirlings-approximation-formula-clojure /

I did Anagram excersize , qui est comme Count Change problème, mais avec 50 000 coupures (pièces de monnaie). Je suis pas sûr que cela peut être fait de manière itérative , je ne m'inquiète pas. Je sais juste que l'option-xss n'a eu aucun effet -- j'ai toujours échoué après 1024 stack frames (peut-être que scala fait du mauvais travail en livrant à java ou à la limitation printStackTrace. Je ne sais pas). C'est une mauvaise option, comme expliqué de toute façon. Vous ne voulez pas tous les fils dans l'application pour être monstrueux. Cependant, j'ai fait quelques expériences avec de nouveaux Thread (stack size). Cela fonctionne en effet,

  def measureStackDepth(ss: Long): Long = {
    var depth: Long = 0
      val thread: Thread = new Thread(null, new Runnable() {
        override def run() {
          try {
          def sum(n: Long): Long = {depth += 1; if (n== 0) 0 else sum(n-1) + 1}
          println("fact = " + sum(ss * 10))
          } catch {
            case e: StackOverflowError => // eat the exception, that is expected
          }
        }
      }, "deep stack for money exchange", ss)
      thread.start()
      thread.join()
    depth
  }                                               //> measureStackDepth: (ss: Long)Long


  for (ss <- (0 to 10)) println("ss = 10^" +  ss + " allows stack of size " -> measureStackDepth((scala.math.pow (10, ss)).toLong) )
                                                  //> fact = 10
                                                  //| (ss = 10^0 allows stack of size ,11)
                                                  //| fact = 100
                                                  //| (ss = 10^1 allows stack of size ,101)
                                                  //| fact = 1000
                                                  //| (ss = 10^2 allows stack of size ,1001)
                                                  //| fact = 10000
                                                  //| (ss = 10^3 allows stack of size ,10001)
                                                  //| (ss = 10^4 allows stack of size ,1336)
                                                  //| (ss = 10^5 allows stack of size ,5456)
                                                  //| (ss = 10^6 allows stack of size ,62736)
                                                  //| (ss = 10^7 allows stack of size ,623876)
                                                  //| (ss = 10^8 allows stack of size ,6247732)
                                                  //| (ss = 10^9 allows stack of size ,62498160)

vous voyez que la pile peut croître de façon exponentielle plus profondément avec une quantité exponentielle de la pile affectée au fil.