What is MethodArea? Is it stack itself?

[Vishal Hegde]

What is MethodArea? Is it stack itself???

[Rob Spoor]

Where did you find this term? Because if I use Google to search for it I find only 131 results, including this thread.

[Ernest Friedman-Hill]

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".

[Vishal Hegde]

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?

[Vishal Hegde]

Rob Spoor wrote:Where did you find this term? Because if I use Google to search for it I find only 131 results, including this thread.

I heard it from one of my seniors

[Ernest Friedman-Hill]

Vishal Hegde wrote:
But When we split the terminology method area ..it means area for methods and methods are stored in stack, right?

The stack is for stack frames -- local variables and return addresses. The stack is a temporary scratch area, and nothing is "stored" there.

I'm entirely unclear on why you're arguing with me, anyway; you asked what this term means, and I told you.

[Hunter McMillen]

So methods are stored in the heap?

I though that methods were local to a class' activation record on the runtime stack. is this wrong?

Hunter

[Paul Clapham]

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.

[Ernest Friedman-Hill]

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.

[Jesper de Jong]

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.

[Campbell Ritchie]

I hardly think this is a "beginning" question, so I shall move it.