The recent preparation of the production environment JDK upgrade to 1.8, the local first upgrade, found that-xx:permsize and-xx:maxpermsize have failed, replaced by a new area--metaspace (metadata area).
In JDK 1.7 and previous JDK versions, Java class information, Chang, and static variables are stored in the Perm (permanent generation). The metadata and static variables of the class are assigned to Perm when the class is loaded, and the garbage collector handles the metadata and static variables of the class from Perm when the class is unloaded. Of course, the constant pool of things will be Perm garbage collection when the processing.
JDK 1.8 's transformation of the JVM architecture puts the class metadata into local memory, plus the constant pool and static variables in the Java heap. The hotsopt VM will explicitly allocate and free local memory for the class's metadata. In this architecture, the meta-information breaks the original-xx:maxpermsize limit and can now use more local memory. This solves some of the often full GC problems that generated a large number of classes at run time, such as using reflection, proxy, etc. at run time.
allocating local memory to class metadata on a data structure called "block", non-homogeneous metadata will be stored in blocks of different sizes. Each block is associated with a classloader, and all the metadata loaded by the ClassLoader is stored under this block in the space allocated by the class loader. The size of the different application blocks will be different, and the allocation of the block size will be limited by internal fragmentation and external fragmentation. When the ClassLoader is no longer in use, all the block space associated with the ClassLoader will be freed.
if server memory is sufficient, the simplest way to upgrade to JDK 1.8 to modify JVM parameters is toThe-xx:permsize and-xx:maxpermsize parameters are replaced with-xx:metaspacesize and-xx:maxmetaspacesize, because now only the metadata information is stored, giving it a large space is certainly no problem. But the space is piled up because now more storage of the original Chang and static variables in the permanent generation may need to be expanded slightly. Specific tradeoffs and tuning can be made based on GC logs and tools under the $JAVA/bin
Reference and Reference: http://openjdk.java.net/jeps/122 http://bugs.java.com/view_bug.do?bug_id=696293 1
jvm--Removing permanent generations
