How does the JVM know the location of a variable in the method stack?

Question

This question may be stupid or may be a duplicate. I am confused about how variables are popped from the stack when a program refers to this variable. The object is stored on the heap, and the location is stored in the reference variable, and the reference variable containing the heap address itself is stored on the stack. But how does the JVM figure out that the reference variable is stored in which place on the stack.

Let's look at an example to just understand what I'm confused about.

Class Test { public void test() { Object a = new Bar(); Object b = new Foo(); System.out.println(a); } } 

Suppose the test () method is executed. This way the stack will be allocated for test ().

Now that the line ' Object a = new Bar (); ', the Bar object will be created on the heap and the actual variable ' a ' , whose value is the address location of the Bar object, will be stored on the test () stack.

Again on the line ' Object b = new Foo (); . The same thing is happening. The Foo object will be created on the heap, and the actual variable 'b' , whose value is the location address of the Foo object, will be stored on the test () stack.

Now that the line ' System.out.println (a); ', as the JVM knows from which place on the stack, the value of ' a ' should be retrieved. Determines what binds the variable 'a' and its location on the stack?

Answer 1

You are almost there, there is only one missing link in your understanding.

Local variables (or references to an object stored in a local variable, if we are talking about non-primitive types) are actually stored in the local variable table, and not in the operand stack. They only get inserted into the stack when they are used by the call.

(what is confusing is that the local variable table itself is also stored on the stack, but it is a separate stack from which the bytecode for the operands is used. From the point of view of the bytecode, this is a real table with a fixed size and freely indexable. )

You can use javap to see which bytecode is generated from your code. What you will see is something like this:

 public void test(); descriptor: ()V flags: ACC_PUBLIC Code: stack=3, locals=3, args_size=1 0: new #2 // class Test$Bar 3: dup 4: invokespecial #3 // Method Test$Bar."<init>":()V 7: astore_1 8: new #4 // class Test$Foo 11: dup 12: invokespecial #5 // Method Test$Foo."<init>":()V 15: astore_2 16: getstatic #6 // Field java/lang/System.out:Ljava/io/PrintStream; 19: aload_1 20: invokevirtual #7 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V 23: return } 

First of all, what is this line?

  stack=3, locals=3, args_size=1 

This is the metadata that tells the JVM that this method has a operand stack of not more than 3 entries, 3 local variables and takes 1 argument. But, of course, this is wrong, our method takes no arguments and obviously has only two local variables!

The answer to this question is that non-static methods always have a "0th argument": this . This explains the number of arguments and leads us to the following important discovery: the method arguments are also stored in the local variable table . Thus, our table will have records 0,1,2, with 0 containing this at the beginning and 1 and 2 uninitialized.

With that in mind, take a look at the code! First select lines 0-7 :

• The operation code new creates a new instance of Bar and stores the link on the stack.
• dup creates a copy of the same help at the top of the stack (so you now have two copies)
• invokespecial #3 calls the constructor of Bar and consumes the top of the stack. (now we have only one copy left)
• astore_1 stores the remaining link in the local variable number 1 ( 0 for this in this case)

This is what Object a = new Bar(); was compiled Object a = new Bar(); . Then you get the same for Object b = new Foo(); (lines 8-15 ).

And then an interesting bit appears, from line 16 :

• getstatic #6 pushes the value of System.out the stack
• aload_1 pushes local variable number 1 ( a ) on the stack.
• invokevirtual #7 consumes both entries by calling println() on System.out with a as an input parameter.

If you want to delve deeper into it or just want to point out my mistakes, the official link to all of the above is here .

Answer 2

The JVM stores Stack Frames and these hold arrays for variables.

 Each frame (§2.6) contains an array of variables known as its local variables. [...] Local variables are addressed by indexing. 

Found here

Answer 3

The JVM is not a one-time data structure; in fact, it has several different mechanisms. When the program is executed, the JVM organizes all the memory it needs and allocates them into several different memory stacks, called run-time data areas.

Here is a more detailed explanation: JVM Architecture