Java 8: from PermGen to MetaSpace
(An abridged translation of an article by Pierre-Hughes Charbonne)
As previously reported on Java One, in Java 8 version of HotSpot it is planned to abandon the PermGen space in favor of its new variation - Metaspace. Early access to JDK 8 makes it possible to observe Metaspace in action, which the author of the original article took advantage of to find out what advantages MetaSpace provides in comparison with PermGen, and make sure of everything directly.
Details under the cut.
')
As part of the HotSpot merge with JRockit, class metadata will be stored in native memory, similar to JRockit and IBM JVM. Part of the native memory allocated for this metadata is called Metaspace.
So, Metaspace is a replacement for PermGen , the main difference from which, from the point of view of Java programmers, is the ability to dynamically expand , limited by default only by the size of native memory. The PermSize and MaxPermSize parameters are now abolished (having received these parameters, the JVM will warn that they are no longer valid), and the optional parameter MaxMetaspaceSize is entered instead , through which you can set a limit on the size of Metaspace.
As a result , the default maximum Metaspace is not limited by anything except the limit of the amount of native memory . But it can be optionally limited to the MaxMetaspaceSize parameter, which is essentially similar to MaxPermSize.
It is assumed that in this way it will be possible to avoid the error “java.lang.OutOfMemoryError: PermGen space” due to the greater flexibility of dynamic resizing of Metaspace. But, of course, if the size of Metaspace reaches its limit - whether it is the maximum amount of native memory, or the limit specified in MaxMetaspaceSize - a similar exception will be thrown: "java.lang.OutOfMemoryError: Metadata space".
The logs of the Garbage Collector will also report garbage collection in Metaspace.
The garbage collection itself, according to the author of the article, will occur when Metaspace reaches the size specified in MaxMetaspaceSize . But his experiments (see below) show that when MaxMetaspaceSize is not specified, garbage collection in Metaspace is also performed before each dynamic increase .
The author of the article carried out three experiments on filling PermGen Space / Metaspace (all on 64-bit JVM weights):
As a result, the author found that:
In the original article, the author also provides graphics memory usage and the logs of the Garbage Collector - for those who are interested. Charts and logs should be clear without translation.
From myself I will add that such innovation can be useful for running java code on client machines. For example, ant / maven build scripts, which previously sometimes had to raise MaxPermSize to successfully complete the build. And it will also be very useful in those (albeit rare) cases when using desktop Java applications, for which PermGen has never made much sense.
As previously reported on Java One, in Java 8 version of HotSpot it is planned to abandon the PermGen space in favor of its new variation - Metaspace. Early access to JDK 8 makes it possible to observe Metaspace in action, which the author of the original article took advantage of to find out what advantages MetaSpace provides in comparison with PermGen, and make sure of everything directly.
Details under the cut.
')
What is Metaspace
As part of the HotSpot merge with JRockit, class metadata will be stored in native memory, similar to JRockit and IBM JVM. Part of the native memory allocated for this metadata is called Metaspace.
So, Metaspace is a replacement for PermGen , the main difference from which, from the point of view of Java programmers, is the ability to dynamically expand , limited by default only by the size of native memory. The PermSize and MaxPermSize parameters are now abolished (having received these parameters, the JVM will warn that they are no longer valid), and the optional parameter MaxMetaspaceSize is entered instead , through which you can set a limit on the size of Metaspace.
As a result , the default maximum Metaspace is not limited by anything except the limit of the amount of native memory . But it can be optionally limited to the MaxMetaspaceSize parameter, which is essentially similar to MaxPermSize.
It is assumed that in this way it will be possible to avoid the error “java.lang.OutOfMemoryError: PermGen space” due to the greater flexibility of dynamic resizing of Metaspace. But, of course, if the size of Metaspace reaches its limit - whether it is the maximum amount of native memory, or the limit specified in MaxMetaspaceSize - a similar exception will be thrown: "java.lang.OutOfMemoryError: Metadata space".
Garbage collection
The logs of the Garbage Collector will also report garbage collection in Metaspace.
The garbage collection itself, according to the author of the article, will occur when Metaspace reaches the size specified in MaxMetaspaceSize . But his experiments (see below) show that when MaxMetaspaceSize is not specified, garbage collection in Metaspace is also performed before each dynamic increase .
Experiments
The author of the article carried out three experiments on filling PermGen Space / Metaspace (all on 64-bit JVM weights):
- JDK 1.7, MaxPermSize = 128 MB
- JDK 1.8 (b75), MaxMetaspaceSize is not set
- JDK 1.8 (b75), MaxMetaspaceSize = 128 MB
As a result, the author found that:
- with MaxPermSize = 128 MB on JDK 1.7, he managed to load a little more than 30 thousand classes before throwing out the “OutOfMemoryError: PermGen space” exception.
- in the absence of the MaxMetaspaceSize limit on JDK 1.8, his program loaded 50 thousand classes (he never tried again) without receiving exceptions
- with the MaxMetaspaceSize limit of 128 MB on JDK 1.8, the result was similar to MaxPermSize = 128 MB on JDK 1.7 - we managed to load a little over 30 thousand classes before throwing out the “OutOfMemoryError: Metadata space” exception
In the original article, the author also provides graphics memory usage and the logs of the Garbage Collector - for those who are interested. Charts and logs should be clear without translation.
From myself I will add that such innovation can be useful for running java code on client machines. For example, ant / maven build scripts, which previously sometimes had to raise MaxPermSize to successfully complete the build. And it will also be very useful in those (albeit rare) cases when using desktop Java applications, for which PermGen has never made much sense.
Source: https://habr.com/ru/post/169869/
All Articles