Question

I’ve come to write the following code:

public class foo {

    static int iterationCounter = 0;

    public foo() {
        iterationCounter++;
        System.out.println(iterationCounter);
        new foo();

    }

    public static void main(String[] args) {
        new foo();

    }


}

Before a StackOverflow Exception was generated, the last log made of the value iterationCounter was: 11472, hence Java set aside x amount of memory to create 11472 foo objects.

Yet the following code outputs a different log than that of the other program:

public class foo {

    static int iterationCounter = 0;
    foo fooObject;

    public foo() {
        iterationCounter++;
        System.out.println(iterationCounter);
        this.fooObject = new foo();

    }

    public static void main(String[] args) {
        new foo();

    }


}

Here comes my confusion in regards of the memory management. I thought that the value of iterationCounter would be the same as that of the other program, yet the value this time is 9706. Since fooObject is a public variable (a field), it should be stored in the heap memory (not so?) and not in the stack memory. If this would be the case it should not consume space of the stack (or is is storing all the new created fooObjects and all their properties in the stack)?

Answer 1

The first version generates the following code (output of javap -c ...):

   ...                                     
   18:  invokevirtual   #4; //Method java/io/PrintStream.println:(I)V            
   21:  new     #5; //class Test                                                 
   24:  dup                                                                      
   25:  invokespecial   #6; //Method "<init>":()V                                
   28:  pop                                                                      
   29:  return          

and the second one – the following:

   ...                                       
   18:  invokevirtual   #4; //Method java/io/PrintStream.println:(I)V                 
   21:  aload_0                                                                       
   22:  new     #5; //class Test                                                      
   25:  dup                                                                           
   26:  invokespecial   #6; //Method "<init>":()V                                     
   29:  putfield        #7; //Field test:LTest;                                       
   32:  return 

As you can see, the only difference between these listings before the recursive call is aload_0 at line 21 in the second listing.

That operation loads a value of a local variable 0 (it’s this) onto the stack, so that it can be used later as an object reference by putfield operation.

So, the difference you observe is caused by presence of one extra entry per invocation on the stack – a this reference to be used to write a value into a field.