Java8 's JVM persistent generation-where to go?

This article describes some of the basic concepts of the JVM memory structure, and then quickly goes on to the persistence generation, to see where it went after the release of Java SE 8.

Basic knowledge

The JVM is just another process running on your system, and all this magic starts with a Java command. As with any operating system process, the JVM also needs memory to complete its run-time operations. Remember that--JVM itself is a layer of software abstraction of the hardware, on which you can run Java programs, as well as the platform independence and Wora that we boast about (once written, run everywhere).

Quickly go over the JVM's memory structure

As the virtual machine specification says, the memory in the JVM is divided into 5 virtual zones.

• Heap
• Method Area (non-heap)
• JVM Stacks
• Local stack
• PC Register

Heap

• Every object allocated in your Java program needs to be stored in memory. The heap is where these instantiated objects are stored. Yes-it's all about the new operator, it's full of your Java heap!
• It is shared by all threads
• The JVM throws a Java.lang.OutOfMemoryError exception when the heap is exhausted
• The size of the heap can be adjusted by JVM options-xms and-xmx

The heap is divided into:

• Eden Zone-Objects with a new object or short life span are stored in this area, and the size of this area can be adjusted by-xx:newsize and-xx:maxnewsize parameters. The New Generation GC (garbage collector) cleans up this area.
• Survivor Area-the still-quoted objects that survived the garbage collection in the Eden area will stay in this area. The size of this area can be adjusted by the JVM parameter-xx:survivorratio.
• The old days-those who survived the multiple GC after the Eden and Survivor districts (and, of course, the lingering references) were stored in the area. This area will be handled by a special garbage collector. The recycling of objects in older generations is performed by GC (major GC) in the old age.

Method area

• Also known as a non-heap zone (in the implementation of the Hotspot JVM)
• It is divided into two main sub-regions

Persistent generations-this area stores class-related data including class definitions, structures, fields, methods (data and code), and constants. It can be adjusted by-xx:permsize and-xx:maxpermsize. If it is run out of space, it will cause an exception to java.lang.OutOfMemoryError:PermGen space.

Code caching-This cache area is used to store compiled code. The compiled code is native code (hardware-related), which is generated by the JIT (Just in time) compiler, which is unique to the Oracle HotSpot JVM.

JVM Stacks

• is closely related to the methods in the Java class
• It stores the local variable and the intermediate result of the method call and the return value
• Each thread in Java has its own stack, which is inaccessible to other threads.
• Can be adjusted by JVM option-XSS

Local stack

• For local methods (not Java code)
• Assign by thread

PC Register

• program counters for specific threads
• Contains the address of the instruction that the JVM is executing (its value is undefined if it is a local method)

Well, that's the basics of the JVM's memory partitioning. Let's talk about the topic of enduring generations.

So where's the last generation?

In fact, the persistent generation has been completely removed, replacing it with another memory area also known as the meta-space.

Meta-space-Quick Start

• It is part of the local heap memory
• It can be adjusted by-xx:metaspacesize and-xx:maxmetaspacesize.
• When the threshold specified by Xx:metaspacesize is reached, it starts to clean the area
• If the memory in the local space is exhausted, you receive an error message for java.lang.OutOfMemoryError:Metadata space.
• The JVM parameters associated with the persistence generation-xx:permsize and-xx:maxpermsize will be ignored.

Of course, this is just the tip of the iceberg. To get a deeper understanding of the JVM, the best data is its own virtual machine specification!

From: The persistent generation of the JVM-where to go?

Java8 's JVM persistent generation-where to go?