-2

I know that the primitives and object references(for objects used inside a method) are stored on the stack frame and the actual objects are stored on heap. But I am not very clear on where the references to instance variables(which are reference type) are stored.

Can someone please explain where are those references(for instance variables) stored and if a methods wants to use any of the instance variables, then how exactly it works?

Rahul Gupta
  • 1,079
  • 2
  • 15
  • 27
  • 1
    They're technically pointers and not references – Zoe Jul 26 '20 at 14:52
  • Does this answer your question? [How is the java memory pool divided?](https://stackoverflow.com/questions/1262328/how-is-the-java-memory-pool-divided) – Govinda Sakhare Jul 26 '20 at 14:52
  • @Progman, my question is not answered in that link. I am clearly asking about the references and not the actual objects. – Rahul Gupta Jul 26 '20 at 14:55
  • What do you mean by "reference to instance variable" - do you mean instance variables that are reference types, as opposed to instance variables of primitive types? – Joni Jul 26 '20 at 15:00
  • yeah exactly @Joni, that's what I am asking about – Rahul Gupta Jul 26 '20 at 15:01

2 Answers2

3

All instance variables are stored within the object, on the heap. There is no distinction between reference and primitive type variables in this. The value of the variable is a "reference" or "pointer" that is either the special null value, or it points to an object, through an implementation-specific mechanism (OpenJDK HotSpot JVM calls it "oop" - supposedly from "ordinary object pointer").

You can read more about the memory layout of objects in

Another matter is how instance variables are stored within the object: in what order do the go, or if they are stored packed. Instance variables are most likely not stored in source code order, but the details of this vary a lot between JVM implementations and versions.

OpenJDK now includes a tool you can use to inspect the object layout: http://openjdk.java.net/projects/code-tools/jol/

Joni
  • 108,737
  • 14
  • 143
  • 193
1

Given:

public class Example {
    static String staticField = "staticField";
    String instanceField = "instanceField";

    public void foo() {
        String local = "local";
    }
}

staticField

The string itself is on the heap, like all strings are. The static field named staticField is a reference that points at this. There's only one such reference (there is one place in memory of (usually*) 4 to 8 bytes pointing at it. This 'place in memory' is a bit tricky as to where it lives; generally on the heap, same place class files live.

instanceField

This is much simpler to answer. There is no such field, at all, until someone makes a new object. And objects are.. on the heap. Imagine some entirely different code:

public void foo() {
    Example e = new Example();
}

This makes a new Example object and in so doing, we now have one instance of instanceField. The Example object is created on the heap, it occupies some memory. Part of that memory involves that 4 to 8 byte long reference (pointer) to the "instanceField" string, which also lives on the heap, probably in an entirely different spot. Then, the local field e, which lives on stack, will reference (point at) that.

So, we have e (living on stack), containing a memory address in the heap where an instance of Example lives, and within the memory used by that, there is a memory address that points at a different place on the heap where the string "instanceField" is located.

local

Finally, there's local, which is 4 to 8 bytes on the stack, pointing at a string living on the heap.

*) Any JVM is free to implement this however they want.

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72