https://dzone.com/articles/java-8-permgen-metaspace
Interned strings, for example, have already been removed from the PermGen space since JDK 7.
Java-Latte: Metaspace in Java 8
This is how Heap Structure look like in Java 6
Permanent Generation
The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
The Permanent generation contains metadata required by the JVM to describe the classes and methods used in the application. The permanent generation is populated by the JVM at runtime based on classes in use by the application. In addition, Java SE library classes and methods may be stored here.
Classes may get collected (unloaded) if the JVM finds they are no longer needed and space may be needed for other classes. The permanent generation is included in a full garbage collection
Region of Java Heap for JVM Class Metadata.
Hotspot’s internal representation of Java Classes.
Class hierarchy information, fields, names
Method compilation information and bytecodes
Variables
Constant pool and symbolic resolution
Once exhausted throws OutOfMemoryError "PermGen space".
Size needed depends on number of classes, size of methods, size of constant pools.
The Permanent Generation (PermGen) space has completely been removed and is kind of replaced by a new space called Metaspace.
The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace.
Interned strings, for example, have already been removed from the PermGen space since JDK 7.
The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace; similar to the Oracle JRockit and IBM JVM's.
Metaspace memory allocation model
- Most allocations for the class metadata are now allocated out of native memory.
- The klasses that were used to describe class metadata have been removed.
Metaspace capacity
- By default class metadata allocation is limited by the amount of available native memory (capacity will of course depend if you use a 32-bit JVM vs. 64-bit along with OS virtual memory availability).
- A new flag is available (MaxMetaspaceSize), allowing you to limit the amount of native memory used for class metadata. If you don’t specify this flag, the Metaspace will dynamically re-size depending of the application demand at runtime.
Metaspace garbage collection
- Garbage collection of the dead classes and classloaders is triggered once the class metadata usage reaches the “MaxMetaspaceSize”.
- Proper monitoring & tuning of the Metaspace will obviously be required in order to limit the frequency or delay of such garbage collections. Excessive Metaspace garbage collections may be a symptom of classes, classloaders memory leak or inadequate sizing for your application.
Java heap space impact
- Some miscellaneous data has been moved to the Java heap space. This means you may observe an increase of the Java heap space following a future JDK 8 upgrade.
This is how Heap Structure look like in Java 6
The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
The Permanent generation contains metadata required by the JVM to describe the classes and methods used in the application. The permanent generation is populated by the JVM at runtime based on classes in use by the application. In addition, Java SE library classes and methods may be stored here.
Classes may get collected (unloaded) if the JVM finds they are no longer needed and space may be needed for other classes. The permanent generation is included in a full garbage collection
Region of Java Heap for JVM Class Metadata.
Hotspot’s internal representation of Java Classes.
Class hierarchy information, fields, names
Method compilation information and bytecodes
Variables
Constant pool and symbolic resolution
Once exhausted throws OutOfMemoryError "PermGen space".
Size needed depends on number of classes, size of methods, size of constant pools.
The Permanent Generation (PermGen) space has completely been removed and is kind of replaced by a new space called Metaspace.
Why was PermGen Eliminated?
- Fixed size at startup – difficult to tune.
- -XX:MaxPermSize=?
- Internal Hotspot types were Java objects : Could move with full GC, opaque, not strongly typed and hard to debug, needed meta-metadata.
- Simplify full collections : Special iterators for metadata for each collector
- Want to deallocate class data concurrently and not during GC pause
- Enable future improvements that were limited by PermGen.
- Take advantage of Java Language Specification property : Classes and associated metadata lifetimes match class loader’s.
- Per loader storage area – Metaspace
- Linear allocation only
- No individual reclamation (except for RedefineClasses and class loading failure)
- No GC scan or compaction
- No relocation for metaspace objects
- Reclamation en-masse when class loader found dead by GC
- Most allocations for the class metadata are now allocated out of native memory.
- The classes that were used to describe class metadata have been removed.
- Multiple mapped virtual memory spaces allocated for metadata.
- Allocate per-class loader chunk lists
- Chunk sizes depend on type of class loader.
- Smaller chunks for sun/reflect/Delegating ClassLoader.
- Return chunks to free chunk lists.
- Virtual memory spaces returned when emptied.
- Strategies to minimize fragmentation.
