PermGen space of heap

Question

As shown in the image, Permgen is further divided into several parts.

Runtime constant pool stores constants pertaining to each type that is loaded by class loader.

Method area stores method information such as method return type, method name. (correct me if I am wrong here.)

And Reserved area is the part which is reserved if more memory is required by permgen.

But what I don't understand is, what is code area in the image? Any code is stored in this space(seems vague to me)?

Answer 1

Any code is stored in this space(seems vague to me)?

Any specific reason for that ?

The possible answer could be : Code area stores the byte code of the classes loaded into your memory.

But then the question comes, Why class is not loaded directly in RAM ?

Because we have a JVM to provide interoperability, Since JVM is an intermediary between java code and the machine , we need some place to store the code statements until JVM is scheduled by OS to execute its code.(for OS JVM is a process). So, It loads the byte code in Code area(if i am right) and when scheduled, further interprets code(.class) into underlying machine instructions.

The answer to me is "Code area holds the byte code of the classes".

To back the idea mentioned above ., here are some concepts copied as it is from Oracle blog which says:

So the Java classes are stored in the permanent generation. What all does that entail? Besides the basic fields of a Java class there are:

1. Methods of a class (including the bytecodes)
2. Names of the classes (in the form of an object that points to a string also in the permanent generation)
3. Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).
4. Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).
5. Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
6. Information used for optimization by the compilers (JITs)

Hope it clears.

Answer 2

From an interesting article on the problems of PermGen: Will Java 8 Solve PermGen OutOfMemoryError?:

Jon Masamitsu, JVM developer at Oracle, explained 2006 in his blog the purpose of the permanent generation: The permanent generation contains information about classes, such as bytecode, names and JIT information. It is stored in a separate space, because it is mostly static and garbage collection can be much more optimized by separating it.

Answer 3

Actually the PermGen store all your static code. i think this makes sense to you why there is a code area in PermGen.

Answer 4

I will venture to guess, based on the following article, by Jon Masamitsu, from which the following quote is taken, that the figure above is a misrepresentation (or rephrased - a misleading representation):

So the Java classes are stored in the permanent generation. What all does that entail? Besides the basic fields of a Java class there are

Methods of a class (including the bytecodes)

Names of the classes (in the form of an object that points to a string also in the permanent generation)

Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).

Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).

Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)

Information used for optimization by the compilers (JITs)

Answer 5

The bytecode of all classes that have been resolved live in permgen. Just because a library has 1.2MB of classes doesn't they will be loaded by the JVM from the JAR. It it possible, even likely, that only a small fraction of those classes are used by a particular application.

You can run many large application servers whose sum total JAR size is >1GB using only 64MB permgen, because only a fraction of the classes are ever used.

Also take this example:

class A {
   // ... code
}

class B {
   void method1() {
      // something
   }

   void method2() {
      A a = new A();
   }
}

While these classes may reside in the same JAR, merely creating an instance of B does not cause class A to be loaded. If you never call method2(), class A will never be loaded by the JVM. Additionally, contrary to popular belief, permgen can be garbage collected, and if space gets low, and there are no instances on the heap referring to class A anymore, then class A can be removed from permgen.