Redundant method call reduces available stack memory

Question

I met StackOverflowError in my real project and made simple model that shows the problem. It's test class that calls some recursive method and saves the depth of error.

public class Main {
    static int c = 0;

    public static void main(String[] args) {
        long sum = 0;
        int exps = 100;
        for (int i = 0; i < exps; ++i) {
            c = 0;
            try {
                simpleRecursion();
            } catch (StackOverflowError e) {
                sum += c;
            }
        }
        System.out.println("Average method call depth: " + (sum / exps));
    }

    public static void simpleRecursion() {
        simpleMethod();
        ++c;
        simpleRecursion();
    }
}

There are two versions of simpleMethod:

public static void simpleMethod() {
}

It gets either 51K or 59K method calls' depth in tests.

public static void simpleMethod() {
    c += 0;
}

It gets either 48K or 58K method calls' depth in tests.

Why have these realizations got different results? I can't understand what extra data lies in stack in the second case. In my opinion simpleMethod should not influence stack memory because it's not in call chain.

@HoussemBadri The recursion stops when a stack overflow error is thrown. — khelwood, Dec 26 '20 at 08:56
What's the point of the for-loop? Is just calling `simpleRecursion();` not enough to demonstrate this? — akuzminykh, Dec 26 '20 at 08:58
@khelwood is that the disired behavior or the actual behavior (The fact that having the exception thrown to stop the recursion)? — Houssam Badri, Dec 26 '20 at 09:03
@HoussemBadri They're deliberately causing a stack overflow to see how deep the stack can go. — khelwood, Dec 26 '20 at 09:07
I'm curious on the results of both cases. What do you mean by 51K or 59K? Is it always one of them (approx.) or a range? — Thiyagu, Dec 26 '20 at 09:08
Does this answer your question? [Are there inline functions in java?](https://stackoverflow.com/questions/2096361/are-there-inline-functions-in-java) — Progman, Dec 26 '20 at 12:05
@tgdavies The stack size of `2` (check `javap -v`) will be added to the stack size of `simpleRecursion()` when the method `simpleMethod()` gets inlined. — Progman, Dec 26 '20 at 12:37
@Progman interesting, perhaps you should give that as an answer as I don't think the question you linked to explains that? — tgdavies, Dec 26 '20 at 12:42
@Progman I believe that it can be inline effect, but could you describe where is stack memory saving in that case? in my opinion stack doesn't have simpleMethod's mention anyway — Alexey Shishkin, Dec 26 '20 at 12:49

score 3 · Accepted Answer · answered Dec 26 '20 at 14:07

The issue you experience might be related to inlining methods by the JVM due to performance reasons. Inlining a method might have an affect on the allocated stack size for that method. You can check with javap -v how big the stack size is for a method, which gets allocated when the method is called. For your code the result of javap -v is as follow:

The simpleRecursion() method:

  public static void simpleRecursion();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=0, args_size=0
         0: invokestatic  #13                 // Method simpleMethod:()V
         3: getstatic     #2                  // Field c:I
         6: iconst_1
         7: iadd
         8: putstatic     #2                  // Field c:I
        11: invokestatic  #3                  // Method simpleRecursion:()V
        14: return
      LineNumberTable:
        line 19: 0
        line 20: 3
        line 21: 11
        line 22: 14

The simpleMethod() method without the c+=0; line:

  public static void simpleMethod();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=0, locals=0, args_size=0
         0: return
      LineNumberTable:
        line 25: 0

The simpleMethod(); method with the c+=0; line:

  public static void simpleMethod();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=0, args_size=0
         0: getstatic     #2                  // Field c:I
         3: iconst_0
         4: iadd
         5: putstatic     #2                  // Field c:I
         8: return
      LineNumberTable:
        line 25: 0
        line 26: 8

The method variant with the empty body requires a stack size of 0, where the method variant with the c+=0; line requires a stack size of 2.

My guess it that when the method simpleMethod() gets inlined into simpleRecursion() by the JVM/JIT/HotSpot (see other questions like Are there inline functions in java? or Would Java inline method(s) during optimization?) it will increase the stack size of simpleRecursion() to make room for the required extra stack size of simpleMethod(). Now the stack size of simpleRecursion() is bigger, which results in hitting the limit with a StackOverflowError earlier.

Unfortunately, I cannot verify this since the JIT/HotSpot is involved. Heck, even running the same application multiple times results in different values for c at the end. And when I try it with a simpleRecursion() variant where the c+=0; is used instead of the method call to simpleMethod();, the stack size stays the same, most likely because the compiler is smart enough to work with the same stack size of 2.

Awesome explanation. Thank you. If I make simpleMethod harder enough then there's a chance that stack size for simpleRecursion will be reduced back. Is it true? — Alexey Shishkin, Dec 26 '20 at 14:37

Redundant method call reduces available stack memory

1 Answers1