In the article “inside the JVM architecture” we described the memory structure of the JVM prior to Java7, but the memory structure of the JVM has changed over time in Java8 and later releases. As an interviewer, if you don’t already know, is the interview process showing signs of shyness? As an interviewer, if you are aware of these changes, it will become a bright spot in the interview.
If you search the JVM memory structure on the web, 90% of the time you will find a memory map that looks like Java7 or earlier, this article will take a closer look at the JVM memory structure to understand the internal changes since Java8. Now you realize the benefits of following the public account “Program New Horizon”. Here you can constantly refresh your knowledge and cognition.
Refinement of JVM memory structure
Again, take a look at the memory structure diagram in details of memory Structure in the JVM.
For a more detailed explanation, we will further optimize and adjust the figure. Refinements for java7 and earlier versions.
See the change? The heap is connected to the method area, but this does not mean that the heap and the method area are together, they are still logically separate. But physically, they are contiguous chunks of memory. In other words, the method area is continuous with Eden and the old age mentioned above.
Before we go any further, let’s understand two concepts: specification and implementation.
Specification and implementation
The Java Virtual Machine Specification is specific to the implementation of Java virtual machines (VMS). Different vendors implement different VMS based on the specifications. Just like defining the interface in the development process, the specific interface implementation can be implemented according to different business requirements.
PS: It is important for everyone to take a look at the Java VIRTUAL Machine Specification. Please follow the public account “Program New Vision” and reply “002” to obtain the PDF version of the Java SE 7 virtual Machine specification.
The most commonly used Versions of Java SE are provided by the Sun JDK and OpenJDK, which are the most widely used versions. The VM that this version uses is HotSpot VM. Usually, the Java virtual machine we’re talking about is the HotSpot version.
PermGen
With the specification and implementation understood above, it is time to recognize the concept of “Permanet Generation” (also known as PermGen). For programmers who are used to developing and deploying on a HotSpot virtual machine, many prefer to refer to the method area as a persistent generation.
In essence, the two are not equivalent, simply because Hotspot extends GC generation to the method area, or uses persistent generation to implement the method area. On other virtual machines there is no concept of a permanent generation. That is, the method area is the specification and the persistent generation is Hotspot’s implementation of that specification.
With these concepts in mind, let’s make a few more changes to the construction of the heap and method areas in Java7 and earlier versions.
Again, for Java7 and previous versions of Hotspot, the method area is in a persistent generation. Meanwhile, the permanent generation and heap are isolated from each other, but they use continuous physical memory.
The permanent generation’s garbage collection is tied to the old generation, so whoever fills up triggers the permanent generation and the old generation’s garbage collection.
But some of the data stored in Java7’s persistent generation has already started moving to Java Heap or Native Memory. For example, Symbols are transferred to Native Memory. The string constant pool (Interned Strings) was moved to the Java Heap; Class statics are moved to the Java Heap.
Then, in Java8, times changed and Hotspot did away with persistent generation. The permanent generation has really become a permanent memory. The permanent generation parameters -xx :PermSize and -xx: MaxPermSize are also invalidated.
Dimension (Metaspace)
With Java8, 3.8% removed the permanent generation, so does that mean there’s no method section? Of course not. The method area is just a specification, but its implementation has changed.
In Java8, Metaspace takes the stage, and method areas live in Metaspace. At the same time, the meta space is no longer contiguous with the heap, but exists in Native memory.
Native memory, also known as C-heap, is used by the JVM’s own processes. GC is triggered when the Java Heap space is low, but not when the Native Memory space is low.
For the tweaks to Java8, we again tweaked the memory structure diagram.
Yuan space exists in local memory, means that as long as local memory enough, it won’t appear like permanent generation “Java. Lang. OutOfMemoryError: PermGen space” this kind of mistake. Look at the method area in the figure above to see if it is “inflated”.
By default, the meta-space can make unlimited use of local memory, but to keep it from ballooning, the JVM also provides parameters to limit its use.
- -xx :MetaspaceSize, the initial space quota of class metadata. Bytes trigger garbage collection for type offloading, and the GC adjusts the value. If a large amount of space is freed, the value is reduced. If very little space is freed, increase the value appropriately until it does not exceed MaxMetaspaceSize (if set).
- -xx: MaxMetaspaceSize indicates the maximum space that can be allocated for class metadata. The default is unlimited.
- -xx: MinMetaspaceFreeRatio, the minimum percentage of Metaspace free space capacity after GC to reduce garbage collection caused by allocating space for class metadata.
- After – XX: MaxMetaspaceFreeRatio, GC, the biggest Metaspace the percentage of the remaining space capacity, reduced to class metadata release space to garbage collection.
What is the permanent substitute replaced
Think about it, why do you use a meta-space instead of a permanent generation?
Ostensibly to avoid OOM exceptions. Because it is common to use PermSize and MaxPermSize to set the size of the permanent generation to determine the upper limit of the permanent generation, it is not always possible to know how appropriate it should be, and it is easy to get OOM errors if you use the default.
When using meta-space, the number of classes of metadata that can be loaded is no longer controlled by MaxPermSize, but by the actual available space on the system.
The deeper reason is to merge HotSpot and JRockit code, JRockit never had a so-called persistent generation, nor did it require development operations to set the size of the persistent generation, but it worked fine. There are also no performance issues to worry about. In the tests covered, the application was up and running less than 1% slower, but this performance penalty is worth more security.
summary
Have you gained a better understanding of the JVM’s memory structure? It’s time to spend a little more time with the interviewer, who doesn’t have much time. Also, don’t miss a pass by, the series continues to be updated. Finally, don’t forget to follow the public account “Program New Vision” for first-hand information.
Java8 JVM memory structure changed, permanent generation to meta space
The Interviewer series:
- JVM Memory Structure In Detail
- Interviewer: Stop asking me about Java GC garbage Collection
- Java8 JVM memory structure changed, permanent generation to meta space
Program new horizon