PermGen space is familiar to anybody who has
debugged memory issues in large JEE applications. Starting with JDK 8, it is being removed. The
JDK Enhancement Proposal says "remove", but it's more like it's being
moved to native memory outside the JVM.
The goal as mentioned in the JEP is
"to remove the need to tune the size of the permanent generation."
The
beginnings of the change are already in JDK7, with interned strings
being no longer part of the PermGen, but of the main Java heap -
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962931
There's a summary of changes in the OpenJDK mailing list
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html
What does this mean for Java developers? Well, at least the following
- There will no longer be any need to set the sizes of the Perm Gen space with JVM startup parameters.
- The class metadata previously stored in the PermGen will now be stored in a native memory space called "Metaspace".
- The default maximum size of the metaspace will be limited only by the available memory on the machine. However, it can be limited by using the MaxMetaspaceSize option.
- It's not entirely clear yet as to how debugging tools like jmap and jhat will change, if at all, as a result of this, or if it will bring in more complications.
And of course, if you have classloader-leaks-based OutOfMemory problems in your application, they are not magically going away. They will just be transferred to another space with more memory than is allocated to your JVM now.
I could not find any reference to the origin of the term "metaspaces" except in this paper (PDF) - http://www.ssw.uni-linz.ac.at/General/Staff/TS/optimized_class_metadata_memory_management_in_a_jvm.draft.pdf
Familiarity with the JVM's memory management strategies is required to understand it - which I don't have currently - so it's on my to-read list as of now.
No comments:
Post a Comment