I've seen "method area" used to refer to that part of memory to which code is loaded. It's part of the heap -- in particular, in Sun's JVMs it's an area of the heap known as the "permanent generation", or "PermGen space".
Ernest Friedman-Hill wrote:I've seen "method area" used to refer to that part of memory to which code is loaded. It's part of the heap -- in particular, in Sun's JVMs it's an area of the heap known as the "permanent generation", or "PermGen space".
But When we split the terminology method area ..it means area for methods and methods are stored in stack, right?
Methods are permanent, unchanging, and they are the same for all instances of a class. So the simple and logical thing would be to keep one copy of each method of a class in a permanent place. And, unsurprisingly, that's how it is done.
By "methods are stored in the heap", I mean that the data structures representing a method to the JVM, including its bytecode, are stored in the heap when they are loaded from the class files. We have several people now saying that they believe "methods are stored on the stack", and that's simply not true, by this definition of "methods".
What is stored on the stack(s) is the information about which method called which other method in a given thread, and the values of the local variables in each executing method. This is information about the execution of methods, rather than methods themselves. Note that each thread has its own stack, a fact that seems to often be overlooked in these discussions.
It's important to understand what the stack is exactly, instead of just remembering "this is on the heap, and that is on the stack" without understanding why or how it works.
To understand exactly what the stack is, read this Wikipedia article: Call stack. It explains exactly what the stack is for and how it works.
Note that most microprocessors, including all microprocessors used in PCs, have built-in instructions that support a call stack. For example, the processor has a jump-to-subroutine (JSR) instruction which saves the state of many of the processor's registers and the location in memory of the instruction after the JSR instruction on the stack, and then jumps to the address of the subroutine. At the end of the subroutine is a return instruction (RET) which pulls this information off the stack to restore the registers to the state they were in before the subroutine was called, and which jumps to the saved address. So the mechanism of the call stack is a very low-level thing, which is implemented in the hardware of the microprocessor itself. Java uses this mechanism of the processor when methods are called (the JSR and RET instructions).
The call stack is not a general storage area just like the heap, where data or code is stored.