Where methods live? Stack or in Heap?

Question

I know that local variables and paramters of methods live in stack, but I not able to figure out where does actually methods live in case of Java?

If I declare any T

Answer 1

If I remember correctly, the method code itself will live in the code portion of memory, while the variables declared internally will live in the stack, and the objects will be created on the heap. In Java, the variable pointers and primitives live on the stack, while any created objects live in the heap.

For a (poor) ASCII representation:

-------
|STACK|
-------
|FREE |
-------
|HEAP |
-------
|CODE |
-------

Where the STACK represents the stack, FREE represents free memory, HEAP represents the heap, and CODE represents the code space.

This is what my memory says - some of the details might be wrong.

Answer 2

The stack contains all the local variables and all active method invocations. The heap hold everything else.

As for your sub question: it means a new stack is created with its own dedicated memory. While your new thread will share the total heap space (memory) allocated by the jvm

Answer 3

The stack is comprised of method invocations. What java pushes onto the stack is a method invocation record, which encapsulates all the variables (both parameters and locally instantiated variables) for that method. When you start a Java application, the main method (which automatically includes the args parameter) is the only thing on the stack:

main(args)

When say you create a Foo object and call foo.method(), the stack now looks like:

method()
main(args)

As methods get called, they are pushed onto the stack, and as they return, they are removed or "popped" from the stack. As variables are declared and used the stack entry, which corresponds to the current method (at the top of the stack), grows to include the size of the variable.

For your example with threads, each thread will have its own stack which exists independent of each other thread's stack.

Answer 4

Each thread is allocated its own stack.

This article has a good introduction to the memory separation within a Java process.

Inside the Java virtual machine, each thread is awarded a Java stack, which contains data no other thread can access, including the local variables, parameters, and return values of each method the thread has invoked. The data on the stack is limited to primitive types and object references. In the JVM, it is not possible to place the image of an actual object on the stack. All objects reside on the heap.

I've seen many scenarios where clients have implemented hugely threaded servers on the basis that each thread does very little, and they run into problems with memory. That's because each thread is allocated its own stack, and this (obviously) adds up. I think the default value is 512k per thread, but I've not found a canonical source for that.

Answer 5

The actual bytecode and/or JIT'd code would live in the process's memory. There would likely only be one copy of it in the process memory, as all threads in a given process share that memory. Any variables shared by those threads will be accessed by the methods in common. Variables local to the threads (even method local variables used within a thread) will be created within that thread's memory.

Answer 6

The heap is split up into multiple generations.

The bytecode, and its corrosponding JIT compiled machine code lives in the so called permanent generation, along with interned Strings and other class data.

Even though it is called the "permanent" generation, it can still be garbage collected. Some libraries, frameworks and JVM languages generate bytecode at run-time, so the permanent generation sometimes need clean up. Just like the other generations of the heap, but (one usually hopes) less frequently.