In Java 8, PermGen space is completely removed and replace with MetaSpace. Most allocation for class metadata is now allocated in native memory and classes that describe class metadata have been removed now.
Now HotSpot JVM uses native memory for the representation of class metadata. MetaSpace memory limit is unbound i.e not mandatory to define the upper limit of memory usages. Now instead of reserved native memory, it will increase and decrease based on usages and you will not get OutOfMemoryError : PermGen error.
Note: You can define the max limit of MetaSpace but that can cause OutOfMemoryError: Metaspace. Try to define this limit cautiously to avoid memory waste.
After installation of JDK 8 and trying to run Eclipse with the configuration of PermSize and MaxPerSize. You will get a warning message:
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
Reason to remove PermGen from Java 8
There were lots of drawbacks of PermGen :
- Fixed-size at startup: difficult to tune.
- Internal Hotspot types were Java objects: Could move with full GC, opaque, not strongly typed and hard to debug, needed metadata.
- Simplify full collections: Added Special iterators for metadata for each collector.
- Instead of GC pause, now deallocate class data concurrently.
- Enable future improvements that were limited by PermGen.
Advantages of MetaSpace
There are lots of advantage of MetaSpace in terms of performance and memory management:
- Take advantage of Java Specification property: Classes and associated metadata lifetimes match class loaders.
- Per loader storage area: Metaspace
- Linear allocation only.
- No individual reclamation (except for Redefine Classes and class loading failure)
- No GC scan or compaction.
- No relocation for metaspace objects.
To set maximum metaspace size can use the -XX:MaxMetaspaceSize flag and the by default is unlimited based on your machine memory limit. If you don’t specify this max limit flag, the Metaspace will dynamically re-size depending on your application demand at runtime.
This change enables other optimizations and features in the future
- Application class data sharing.
- Young collection optimizations, G1 class unloading.
- Metadata size reductions and internal JVM footprint projects.