Java stack and heap memory management

Question

I want to know how the memory is being allocated in the following program:

public class MemoryClass {

    public static void main(final String[] args) {
        int i = 0;
        MemoryClass memoryClass = new MemoryClass();
        memoryClass.myMethod(memoryClass);
    }

    private void myMethod(final Object obj) {
        int i = 1;
        String s = "HelloWorld!";

    }

}

Now, as far as my understanding goes, the following diagram describes how the memory allocation takes place:

In the above diagram, memory,obj and s, which are in the stack memory, are actually the references to their "actual objects" which are placed inside the heap memory.
Here is the set of questions that come to my mind:

Where are the methods of s stored?
Had I created another object of MemoryClass inside myMethod, would JVM allocate memory for the same methods again inside the stack memory?
Would JVM free the memory allocated to myMethod as soon as it's execution is completed, if so, how would it manage the situation mentioned in question 2(only applicable if JVM allocates memory multiple times to the same method).
What would have been the case, if I had only declared s and did not initialize it, would JVM still allocate memory to all the methods of java.lang.String class,if so,why?

The nice thing about Java is how it hides all of the memory management from you and lets the garbage collector take control. Why do you need to go looking into it? — byxor
@byxor Two direct reasons as far as I know: 1. when SOF or OOM occurs, you have to know them to fix the errors; 2. when trying to better manage the memory in performance tuning, you have to understand them. — Hearen

arcy arcy · Accepted Answer · 2016-12-13T11:54:32

Where are the methods of s stored?

They are stored in the String class object; it is an object loaded by a ClassLoader object when String is first referenced in the program. All the implementations of the JVM that existed when I read about this last never deallocated the memory for a class object once it was loaded. It's on the heap.

Had I created another object of MemoryClass inside myMethod, would JVM allocate memory for the same methods again inside the stack memory?

No, methods and data for objects is kept separately, specifically because the JVM never needs more than one copy of the methods.

Would JVM free the memory allocated to myMethod as soon as it's execution is completed, if so, how would it manage the situation mentioned in question 2(only applicable if JVM allocates memory multiple times to the same method).

No. Java doesn't generally "immediately free memory" of things stored on the heap. It would make things run too slowly. It only frees memory when the garbage collector runs, and it does that only when its algorithm for running the garbage collector decides it is time.

What would have been the case, if I had only declared s and did not initialize it, would JVM still allocate memory to all the methods of java.lang.String class,if so,why?

This depends on the JVM implementation, I think, and maybe the compiler. If you declare a variable and never use it, it is quite possible (and common) for the compiler to notice that there is no use for it and to not put it into the class file. If it isn't in the class file, it is never referenced, and therefore it and its methods are not loaded, etc. If the compiler puts it in anyway but it is never referenced, then the ClassLoader wouldn't have any reason to load it, but I'm a little vague on whether it would get loaded or not. Might depend on the JVM implementation; does it load things because there are variables of the class or only when they are referenced? How many ClassLoader algorithms can dance on the head of a 4-digit PIN?

I encourage you to read about the JVM and ClassLoaders and such; you will gain so much more by reading an explanation of how it works rather than poking at it with examples you can think up.

Java stack and heap memory management

3 Answers

JVM Memory Areas

Heap memory

Young generation

Old generation

Non-Heap memory

Permanent generation

Code cache

Answering OP's questions specifically

Sources of above information and further reading: