JVM8 Meta-space

Reference URL: http://itindex.net/detail/49579-java-%E7%A9%BA%E9%97%B4

http://openjdk.java.net/jeps/122

Http://www.open-open.com/lib/view/open1434962681825.html

In this article we will introduce an update to the JVM, which is the removal of persistent generations. We will explain why we need to remove the persistence generation, and its replacement, meta-space (metaspace). This is the sequel to the previous article garbage collection of memory management.

The heap structure in Java 6 is like this:

Durable generation

The persistent generation contains all the data that can be obtained through reflection in the virtual machine, such as class and method objects. Classes can be shared between different Java virtual machines, so persistent generations are divided into read-only and read-write areas.

The metadata that the JVM uses to describe the classes and methods used in the application is also stored in the persistence generation. How much of the durable space the JVM will use to run depends on how many classes the application uses. In addition, classes and methods in the Java SE library are stored here.

If the JVM finds that the class is no longer needed, it will reclaim (unload) These classes and release their space for use by other classes. The full GC will be recycled for a durable generation.

• The storage area of the metadata for classes in the JVM in the Java heap.
• The internal representation in the hotspot virtual machine corresponding to the Java class is also stored here.
• Class hierarchy information, fields, names.
• The compilation information and byte code of the method.
• Variable
• Chang and Symbolic parsing

The size of the durable generation

• Its upper limit is MaxPermSize, the default is 64M
• Contiguous regions in the Java heap: if stored in a non-contiguous heap space, it is complex and time-consuming to locate a reference to a persistent generation to a new object. Card-table (card table) is a memory set (remembered set) that is used to record the modification of a normal object pointer (oops) in a memory generation.
• The OutOfMemoryError "PermGen space" exception is thrown when a durable proxy is finished. Solution: The application cleans up references to trigger class unloading, increasing the size of the maxpermsize.
• The amount of durable space required depends on the number of classes, the size of the method, and the size of the constant pool.

Why remove persistent generations

• Its size is fixed at startup-it's hard to tune. -xx:maxpermsize, how much good is it set?
• The internal type of the hotspot is also a Java object: It may be moved in the full GC while it is opaque to the application, is non-strongly typed, difficult to track debugging, and requires metadata information (Meta-metadata) to store metadata.
• Simplify full GC: Each collector has a dedicated metadata iterator.
• You can release the class data concurrently without pausing the GC.
• Make it possible for some of the improvements that have been limited to enduring generations

So where's the JVM's meta-data?

Meta-space (Metaspace)

The space of the last generation is completely removed, and it is replaced by a region called meta-space. After the persistent generation is removed, it is clear that the JVM ignores both permsize and MaxPermSize parameters, and that you can no longer see the exception for Java.lang.OutOfMemoryError:PermGen error. the static variables and interned Strings of the original class are transferred to the Java heap area,

Only the class meta-data is in the meta-space.

The hotspot JVM for JDK 8 now uses local memory to represent the metadata of the class, which is called the meta-space.

Meta-space Features:

• Leverages the benefits of the Java language Specification: The life cycle of classes and related metadata is consistent with the ClassLoader.
• Dedicated storage space for each loader
• Linear Distribution Only
• does not reclaim a class individually
• Eliminates GC scanning and compression time
• The position of the object in the meta-space is fixed.
• If the GC finds that a ClassLoader is no longer alive, it will reclaim all the relevant space

A memory allocation model for meta-space

• The vast majority of the class metadata space is allocated from local memory
• The class used to describe the class metadata has also been deleted.
• Multiple virtual memory spaces allocated for metadata
• Assigns a list of memory blocks to each class loader. The size of the block depends on the type of class loader; sun/reflection/proxy class loader blocks are smaller
• To return a memory block and free up a list of memory blocks
• Once the meta-space data is emptied, the virtual memory space is recycled
• Strategies to reduce fragmentation

Let's look at how the JVM allocates virtual memory space for metadata.

You can see how the virtual memory space is allocated (VS1,VS2,VS3), and how the class loader's memory blocks are allocated. CL is the abbreviation for Class loader.

Understanding _mark and _klass pointers

To understand this picture, you have to figure out what these pointers are.

In the JVM, each object has a pointer to its own class, but the pointer simply points to a specific implementation class, not an interface or abstract class.

For a 32-bit JVM:

_mark:4 Byte Constants

_klass: The second field in the memory layout of a 4-byte pointer object to a class (_klass, in a 32-bit JVM, where the offset of the object's position in memory is 4, 64 bits is 8) points to the class definition of the object in memory.

64-bit JVM:

_mark:8 Byte Constants

_klass: A 8-byte pointer to a class

64-bit JVM with pointer compression turned on: _mark:8 byte constant

_klass: A 4-byte pointer to a class

Memory layout for Java objects

Class pointer compression spaces (compressed class Pointer space)

This area is only available if class pointer compression is enabled on a 64-bit platform. For 64-bit platforms, the class pointer compression space (compressed class Pointer space) is introduced in order to compress the size of the _klass pointer in the JVM object.

Memory layout after compressing the pointer

Pointer compression overview

• Open on 64-bit platforms by default

• Using-xx:+usecompressedoops to compress the object pointer "oops" refers to a normal object pointer ("ordinary" object pointers). The object pointers in the Java heap are compressed into 32 bits. Use the heap base address (if the heap is in low 26G memory, the base address is 0)

• To compress a class pointer using the-xx:+usecompressedclasspointers option

• The pointer to the class metadata in the object is compressed into 32 bits

• Class pointer compression space will have a base address

The difference between a meta-space and a class pointer compression space

• The class pointer compression space contains only the metadata of the class, such as Instanceklass, Arrayklass only if the usecompressedclasspointers option is turned on in order to improve performance, the virtual method table in Java is also stored here The type of metadata that is stored here is still decreasing

• The meta-space contains other relatively large metadata for the class, such as methods, bytecode, constant pools, and so on.

The tuning of meta-space

You can use the-xx:maxmetaspacesize parameter to set the maximum value of the meta space, which is not capped by default, that is, your system memory limit is how much it is. The-xx:metaspacesize option specifies the initial size of the meta-space and, if not specified, the meta-space is dynamically resized according to the application's runtime needs.

Tuning of the Maxmetaspacesize

• -xx:maxmetaspacesize={unlimited}
• The size of the meta-space is limited by the memory of your machine
• Limits the amount of memory used by the class's metadata to avoid virtual memory switching and local memory allocation failures. This parameter should be used if the class loader is suspected to be compromised, and should be set if the address space may be exhausted on a 32-bit machine.
• The initial size of the meta-space is 21m--, which is the initial high watermark of the GC, over which the full GC is performed to recycle the class.
• If the GC is too frequent after startup, set the value a bit larger
• Can be set to the same size as a durable generation to delay GC execution time

Tuning of the Compressedclassspacesize

• It only works if-xx:+usecompressedclasspointers is turned on.
• -xx:compressedclassspacesize=1g
• Since this size is fixed at startup, it's best to set it up a bit larger.
• Do not set if not used
• A subsequent JVM might allow the area to grow dynamically. It is not necessary to be contiguous, as long as it is accessible from the base site, and more meta-information may be put back into the meta-space, and the future will be based on the value of Predictedloadedclasscount to set the size of the space

Some tools for meta-space

• Jmap-permstat changed into a jmap-clstats. It is used to print the Java Heap's class loader statistics. For each classloader, it will output its name, whether it is alive, the address, the parent ClassLoader, and the number and size of the classes it has loaded. In addition, the number and size of the residing string (intern) will also be printed.
• JSTAT-GC, this command outputs the meta-space information rather than the persistent generation.
• Jcmd Gc.class_stats provides more information about the size of the class metadata. You need to add the-xx:+unlockdiagnosticvmoptions option when starting a program with this feature.

Improve GC Performance

If you understand the concept of meta-space, it is easy to see that the performance of GC has been improved.

• In full GC, the pointers to metadata for metadata are no longer scanned. Many of the complex metadata-scanning code (especially those inside the CMS) has been removed.
• The meta-space has only a small number of pointers pointing to the Java heap. This includes a pointer to the Java/lang/class instance in the metadata of the class, and a pointer to the Java/lang/class collection in the metadata of the array class.
• No cost of metadata compression
• Reduced scanning of root objects (no longer scans the dictionary of loaded classes inside the virtual machine and other internal hash tables)
• Reduced time for full GC
• G1 in the collector, the class can be unloaded after the concurrent tagging phase is complete

Summarize

• Metadata in the hotspot is now stored in the meta-space. The life cycle of memory blocks in Mmap is consistent with the ClassLoader.
• Class pointer compression space (compressed class pointer space) is still a fixed size, but it has a large space
• Tuning of parameters is possible, but this is not required.
• Other optimizations and new features may be added in the future. For example, application class data sharing, New Generation GC optimization, G1 garbage collector for class recycling, reducing the size of metadata, and memory consumption of internal objects in the JVM.

This is a bit like a reading note, more trivial.

Original article reproduced please indicate the source: Java 8 meta-space in English original link

Description

Move part of the contents of the permanent generation in Hotspot to the Java heap and the remainder to native memory.

hotspot ' s representation of Java classes (referred to here as Class Meta-data) is Currentl Y stored in a portion of the Java heap referred to as the permanent generation. In addition, interned Strings and class static variables is stored in the permanent generation. The permanent generation is managed by Hotspot and must has enough, the class Meta-data, interned Strings and Class statics used by the Java application. Class metadata and statics are allocated in the permanent generation when a class is loaded and was garbage collected from The permanent generation when the class is unloaded. Interned Strings was also garbage collected when the permanent generation was GC ' ed.

the proposed implementation would allocate class Meta-data in native memory and move interned Strings and class statics to the Java heap. Hotspot would explicitly allocate and free the native memory for the class Meta-data. Allocation of new class Meta-data would be limited by the amount of available native memory rather than fixed by the value Of-xx:maxpermsize, whether the default or specified on the command line.

Allocation of native memory for class Meta-data would be do in blocks of a size large enough to fit multiple pieces of CL The Meta-data. Each block would be associated with a class loader and all class Meta-data loaded by that class loader would be allocated by Hotspot from the block for that class loader. Additional blocks is allocated for a class loader as needed. The block sizes'll vary depending on the behavior of the application. The sizes is chosen so as to limit internal and external fragmentation. Freeing the space for the class meta-data would is done while the class loader dies by freeing all the blocks associated WI Th the class loader. Class Meta-data is not being moved during the life of the class.

Alternatives

The goal of removing the need for sizing the permanent generation can is met by has a permanent generation that can gro W. There is additional data structures that would has to grow with the permanent generation (such as the card table and Block offset table). For a efficient implementation the permanent generation would need to look like one contiguous space with some parts that is not usable.

JVM8 Meta-space