Perm space vs Heap space

Question

First, What is the difference between Perm space and Heap space (What and how does the JVM choose to use each memory space)?

Second, but most importantly, what sort of ratio would be recommended for a standard MVC type java application?

Cannabin

Answer 1

The heap stores all of the objects created by your Java program. The heap's contents is monitored by the garbage collector, which frees memory from the heap when you stop using an object (i.e. when there are no more references to the object.

This is in contrast with the stack, which stores primitive types like ints and chars, and are typically local variables and function return values. These are not garbage collected.

The perm space refers to a special part of the heap. See this SO answer for an explanation: What is perm space?

Rasheedarasher

The link you gave says "segment of the heap" - so is it really "a special part of the stack"? It would make much more sense for it to be a part of the heap (or even some sort of static data segment) rather than the stack that just isn't suited for such kind of thing. – Shelve

It is a special part of the heap. I did edit my answer before you commented, but I appreciate the correction anyway :) – Rasheedarasher

any recommendation on the second question? – Cannabin

@Gareth: This isn't something to be worried about. Some JVMs dont even have a dedicated section of memory for the perm space. If you get a java.lang.OutOfMemory exception, then visualize how much perm space is used with this tool: alphaworks.ibm.com/tech/pmat , and then if you are out of perm space (rare in my experience) you can increase the perm space size with the command line option -XX:MaxPermSize=256m to set the perm space size to 256MB. – Rasheedarasher

Ok, I see. So there really isn't any percentage rule or anything. Thanks. – Cannabin

Answer 2

Personally, I wouldn't consider PermGen a special part of the heap.

I'd much prefer to think of heap as a memory area dedicated to store object instances while PermGen as an area dedicated to store class definitions. As a result, a heap's lifecycle is tied to an application while PermGen's lifecycle is tied to a JVM.

One of the best examples why an application and its JVM can have different lifecycle is in a Java EE container. In an app server, applications can be deployed and undeployed without restarting the server. During the undeployment (or redeployment), it's easy to release all the object instances i.e. heap space, but it's rather tricky to clear all the classes loaded by this app from PermGen because some of the classes can still be referenced by the JVM.

One of such case is the Leaking Drivers. When an app is deployed, a JDBC driver is loaded and registered with the DriverManager. When this app is undeployed, the DriverManager lives on and holds a reference to the driver, its original class loader, and everything this class loader loaded. As a result, a memory leak in PermGen is created, but it's no fault of the application's memory management.

It's true that JVMs like JRocket don't have PermGen at all, everything is stored in heap. Only in such context can you call PermGen a "special part" of heap. Even then, we should still view PermGen and heap differently since they have very different purpose and they have very different types of memory leaks.

Update: In Oracle's JDK 8, PermGen is replaced by "Metaspace" and it is now officially part of the heap. We won't need to specifically tune PermGen any more.

Inevasible

Answer 3

You can NOT give names to allocated memory in the heap.

That means int x (its name) is allocated in the stack. You can reach the pointer by its name, so the pointer is in the stack. You can't reach the object by its name, cause it has no name. Accees to the (nameless) object must be by its pointer.

Elwood