Permgen Elimination in Jdk 8

PermGen elimination in JDK 8

Reasons of ignoring these argument is permanent generation has been removed in HotSpot for JDK8 because of following drawbacks

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

The Permanent Generation (PermGen) space has completely been removed and is kind of replaced by a new space called Metaspace.
The consequences of the PermGen removal is that obviously the PermSize and MaxPermSize JVM arguments are ignored and you will never get a java.lang.OutOfMemoryError: PermGen error.

Advantages of MetaSpace

• 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

Metaspace Tuning

The maximum metaspace size can be set using the -XX:MaxMetaspaceSize flag, and the default is unlimited, which means that only your system memory is the limit. The -XX:MetaspaceSize tuning flag defines the initial size of metaspace. If you don’t specify this flag, the Metaspace will dynamically re-size depending of the application demand at runtime.

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

There is improved GC performace also. More Details

Java8 has completely removed permgen space from it's memory area. will it completely stop memory leak issues ? ...

No. Of course memory leaks are still possible. Actually most of memory leaks appear in normal heap, not in permgen/metaspace, so this change don't affect them. For example, one may create a HashMap in static field and gradually fill it without removing elements. This way heap consumption will constantly grow.

Also moving class data from permgen to metaspace doesn't mean that it does not require space. It's just allocated in off-heap region and can be controlled via MaxMetaspaceSize option (infinity by default). This change is mostly internal (makes some things in JVM easier) and does not affect normal programmers. The only visible problem it solves is that with default setting you will now unlikely to have problems when too many classes are loaded. But this will not help you if you have a significant class loader leak: you are still limited by physical memory and swap size on your machine.

What is the difference between PermGen and Metaspace?

The main difference from a user perspective - which I think the previous answer does not stress enough - is that Metaspace by default auto increases its size (up to what the underlying OS provides), while PermGen always has a fixed maximum size. You can set a fixed maximum for Metaspace with JVM parameters, but you cannot make PermGen auto-increase.

To a large degree it is just a change of name. Back when PermGen was introduced, there was no Java EE or dynamic class(un)loading, so once a class was loaded it was stuck in memory until the JVM shut down - thus Permanent Generation. Nowadays classes may be loaded and unloaded during the lifespan of the JVM, so Metaspace makes more sense for the area where the metadata is kept.

Both of them contain the java.lang.Class instances and both of them suffer from ClassLoader leaks. Only difference is that with Metaspace default settings, it takes longer until you notice the symptoms (since it auto increases as much as it can), i.e. you just push the problem further away without solving it. OTOH I imagine the effect of running out of OS memory can be more severe than just running out of JVM PermGen, so I'm not sure it is much of an improvement.

Whether you're using a JVM with PermGen or with Metaspace, if you are doing dynamic class unloading, you should to take measures against classloader leaks, for example by using my ClassLoader Leak Prevention library.

What does -XX:MaxPermSize do?

The permanent space is where the classes, methods, internalized strings, and similar objects used by the VM are stored and never deallocated (hence the name).

This Oracle article succinctly presents the working and parameterization of the HotSpot GC and advises you to augment this space if you load many classes (this is typically the case for application servers and some IDE like Eclipse) :

The permanent generation does not have a noticeable impact on garbage
collector performance for most applications. However, some
applications dynamically generate and load many classes; for example,
some implementations of JavaServer Pages (JSP) pages. These
applications may need a larger permanent generation to hold the
additional classes. If so, the maximum permanent generation size can
be increased with the command-line option -XX:MaxPermSize=.

Note that this other Oracle documentation lists the other HotSpot arguments.

Update : Starting with Java 8, both the permgen space and this setting are gone. The memory model used for loaded classes and methods is different and isn't limited (with default settings). You should not see this error any more.

JDK 8 Memory Layout and garbage collection

PermGen is replaced with Metaspace in Oracle/Sun JDK8, which is very similar. The main difference is that Metaspace can expand at runtime.

What does PermGen actually stand for?

Permanent Generation. Details are of course implementation specific.

Briefly, it contains the Java objects associated with classes and interned strings. In Sun's client implementation with sharing on, classes.jsa is memory mapped to form the initial data, with about half read-only and half copy-on-write.

Java objects that are merely old are kept in the Tenured Generation.

In Java is Permanent Generation space garbage collected?

The PermGen is garbage collected like the other parts of the heap.

The thing to note here is that the PermGen contains meta-data of the classes and the objects i.e. pointers into the rest of the heap where the objects are allocated. The PermGen also contains Class-loaders which have to be manually destroyed at the end of their use else they stay in memory and also keep holding references to their objects on the heap. The "Presenting the Permanent Generation" article by Jon Masamitsu on the Sun / Oracle blog site might help you.

---

Related Topics