JVM internal implementation mechanism CCID

Reprinted: SCID network http://java.ccidnet.com/art/3737/20060427/531299_1.html

1. jvm gc Overview

GC (garbage collection mechanism) is used by JVM to release the memory occupied by objects that are no longer in use. The Java language does not require JVM to have GC, nor does it specify how GC works. However, common JVMs have GC, and most GC uses similar algorithms to manage memory and perform collection operations.

Only after fully understanding the garbage collection algorithm and execution process can we effectively optimize its performance. Some garbage collections are dedicated to special applications. For example, real-time applications primarily aim to avoid spam interruptions, while most OLTP applications focus on overall efficiency. After understanding the workload of the application and the garbage collection algorithm supported by JVM, You can optimize the configuration of the garbage collector.

The purpose of garbage collection is to clear objects that are no longer in use. GC determines whether to collect the object by determining whether the object is referenced by the active object. GC must first determine whether the object can be collected at the time. Two common methods are reference count and Object Reference traversal.

1. Reference count

Reference count stores the number of all references to a specific object. That is to say, when the application creates a reference and the reference is out of the range, the JVM must increase or decrease the number of references as appropriate. When the reference number of an object is 0, garbage collection can be performed.

1. 2. Object Reference Traversal

Early JVMs used reference counting. Currently, most JVMs use Object Reference traversal. Object Reference traversal starts from a group of objects and recursively identifies reachable objects along each link in the entire object graph. If an object cannot be reached from one (at least one) of these root objects, it is collected as garbage. In the object traversal stage, GC must remember which objects can arrive in order to delete inaccessible objects. This is called a mark (marking) object.

Next, the GC will delete the inaccessible objects. During deletion, some GC simply scans the stack, deletes untagged objects, and releases their memory to generate new objects. This is called clearing ). The problem with this method is that the memory will be divided into many small segments, but they are not enough for new objects, but they are very large in combination. Therefore, many GC can reorganize the objects in the memory and compact them to form available space.

To this end, GC needs to stop other activities. This method means that all the work related to the application is stopped and only GC is run. As a result, many mixed requests are added or subtracted during the response. In addition, more complex GC increases or runs at the same time to reduce or clear application interruptions. Some GC uses a single thread to complete this task, while others use multiple threads to increase efficiency.

2. Several garbage collection mechanisms

2. 1. Mark-clear collector

The collector first traverses the object graph and marks reachable objects, then scans the stack to find untagged objects and releases their memory. This type of collector generally uses a single thread to work and stops other operations.

2. Mark-compression collector

It is also called the Mark-clear-compression collector, which has the same mark stage as the Mark-clear collector. In the second stage, the tag object is copied to the new domain of the stack to compress the stack. This collector also stops other operations.

2. 3. Copy the Collector

This collector divides the stack into two fields, which are often called semi-space. Only half of the space is used each time, and the new object generated by JVM is placed in the other half of the space. During GC running, it copies the reachable objects to the other half of the space, thus compressing the stack. This method is applicable to objects with a short lifetime, and objects with a long lifetime of continuous replication result in lower efficiency.

2. 4. incremental collector

The incremental collector divides the stack into multiple domains and collects garbage from only one domain at a time. This can cause small application interruptions.

. Generational collectors

This collector divides the stack into two or more fields to store objects of different lifetime. New objects generated by JVM are generally placed in a certain domain. After a period of time, the existing object will get the validity period and be transferred to a domain with a longer life cycle. The generational collectors use different algorithms for different domains to optimize performance.

. Concurrent collector

Concurrent collectors and applications run simultaneously. These collectors generally have to stop other operations at a certain point (such as during compression) to complete specific tasks, but because other applications can perform other background operations, therefore, the actual time for interrupting other processing is greatly reduced.

2. 7. Parallel collector

The parallel collector uses a traditional algorithm and uses multiple threads to execute their work in parallel. Using multithreading on multiple CPU machines can significantly improve the scalability of Java applications.

3. Sun hotspot 1.4.1 JVM heap size adjustment

Sun hotspot 1.4.1 uses the generational collector, which divides the heap into three main domains: new domain, old domain, and permanent domain. All new objects generated by JVM are placed in the new domain. Once an object goes through a certain number of garbage collection cycles, it will get the validity period and enter the old domain. In the permanent domain, JVM stores class and method objects. In terms of configuration, the permanent domain is an independent domain and is not considered a part of the heap.

The following describes how to control the size of these domains. You can use-XMS and-xmx to control the original size or maximum value of the entire heap.

The following command sets the initial size to 128 MB:

Java-xms128m

-Xmx256m: to control the size of the new domain, you can use-XX: newratio to set the proportion of the new domain in the heap.

The following command sets the entire heap to 128 m, and the ratio of the new domain to 3, that is, the ratio of the new domain to the old domain is, and the new domain is 1/4 or 32 m of the heap:

Java-xms128m-Xmx128m-XX: newratio = 3 You can use-XX: newsize and-XX: maxnewsize to set the initial and maximum values of the new domain.

The following command sets the initial value and maximum value of the new domain to 64 MB:

Java-xms256m-xmx256m-xmn64m

The default size of the permanent domain is 4 MB. When the program is running, JVM will adjust the size of the permanent domain to meet the needs. During each adjustment, the JVM will perform a full garbage collection on the heap.

Use the-XX: maxpersize flag to increase the size of the permanent domain. When WebLogic Server Applications load many classes, you often need to increase the maximum value of the permanent domain. When the JVM loads a class, the object in the permanent domain increases sharply, so that the JVM continuously adjusts the permanent domain size. To avoid adjustment, you can use the-XX: persize flag to set the initial value.

Set the permanent domain initial value to 32 m and the maximum value to 64 m.

Java-xms512m-xmx512m-xmn128m-XX: permsize = 32 m-XX: maxpermsize = 64 m

By default, hotspot uses the replication collector in the new domain. This domain is generally divided into three parts. The first part is Eden, which is used to generate new objects. The other two parts are called Rescue space. When Eden is full, the collector stops the application and copies all reachable objects to the current from rescue space. Once the current from rescue space is full, the collector copies the reachable objects to the current to rescue space. From and to rescue space swap roles. Objects that maintain the activity will be continuously replicated in the rescue space until they are used and transferred to the old domain. -XX: survivorratio can be used to control the size of the new domain sub-space.

Like newration, mirror vorration specifies the ratio of a rescue domain to an Eden space. For example, the following command sets the new domain to 64 m, and Eden to 32 m, each of which occupies 16 m:

Java-xms256m-xmx256m-xmn64m-XX: Required vorration = 2

As mentioned above, by default, hotspot uses the replication collector for the new domain and the tag-clear-compression collector for the old domain. Using the replication collector in the new domain makes a lot of sense, because most of the objects generated by the application are short-lived. Ideally, all transition objects will be collected when they are removed from the Eden space. If this is the case, and objects removed from the Eden space are long-lived, then theoretically they can be immediately moved to the old domain to avoid repeated replication in the rescue space. However, applications cannot fit this ideal state because they have a small portion of long-lived objects. It is best to keep these long-lived objects in the new domain, because copying a small part of the object is always cheaper than compressing the old domain. To control the replication of objects in the new domain, you can use-XX: target1_vorratio to control the proportion of the rescue space (this value is used to set the proportion of the rescue space. For example, if the rescue space is 1 MB, the value 50 indicates 500 k is available ). This value is a percentage and the default value is 50. When a larger stack uses a lower sruvivorratio, the value should be increased to 80 to 90 to make better use of the rescue space. -XX: maxtenuring
The maximum value of threshold can be controlled.

To place all copies and extend the objects from Eden to the old domain, you can set maxtenuring threshold to 0. after the configuration is complete, the rescue space is no longer used. Therefore, set the maximum vorratio value to maximize the Eden space. The settings are as follows:

Java... -XX: maxtenuringthreshold = 0-XX: Export vorratio = 50000...

4. Use of BEA jrockit JVM

BEA WebLogic 8.1 uses the new JVM for the Intel Platform. In the BEA installation directory, you can see a folder similar to jrockit81sp000014.003. This is the directory where the new JVM of Bea is located. Unlike hotspot, which compiles Java bytecode into classes in advance. Jrockit also provides more detailed functions to observe the running status of JVM, mainly the independent GUI Console (only applicable to jrockit can be used to monitor CPU and memory parameters using the console provided by jrockit81sp1_14.003) or WebLogic
Server console.

Bea jrockit JVM supports four garbage collectors:

4.1.1. Generational replication collector

It is similar to the default generation collector working policy. Objects are allocated in the new domain, namely, the nursery in the jrockit document. This collector is best suited for small heap operations on a single CPU machine.

4.1.2. Single-space concurrent collector

The collector uses the complete heap and works with the background thread. Although this type of collector can eliminate interruptions, it takes a long time for the collector to find dead objects and the Collector runs frequently when processing applications. If the processor cannot cope with the garbage generated by the application, it will interrupt the application and disable collection.

The generational concurrency collector uses the exclusive replication collector in the care domain and the concurrent collector in the old domain. Because it is more frequently interrupted than a single space, it requires less memory and the application runs more efficiently. Note, A small nursing domain can cause a large number of temporary objects to be extended to the old domain. This will overload the collector and even sort it out for collection.

4.1.3. Parallel collector

The collector also stops other processes, but uses multithreading to accelerate the collection process. Although it is easier to cause long-time interruptions than other collectors, it can generally make better use of memory and program efficiency.

By default, jrockit uses the generational concurrent collector. To change the collector, use-xgc:. The four collectors are gencopy, singlecon, GENCON, and parallel. You can use-XMS and-xmx to set the initial size and maximum value of the heap. To set the care domain, use-xns: Java-jrockit-xms512m-xmx512m-xgc: GENCON-xns128m... Although jrockit supports the-verbose: GC switch, the output information varies depending on the collector. Jrockit also supports output of memory, load, and codegen.

NOTE: If jrockit JVM is used, you can also use the console (under c: \ Bea \ jrockit81sp1_142.1603 \ bin) that comes with WLS to monitor some data, such as CPU and memery. To construct monitoring, you must add the-xmanagement parameter to startweblogic. CMD when starting the service.

5. How to get information from JVM for Adjustment

-The verbose. GC switch displays the GC operation content. Open it to display the time when the busiest and idle collection behaviors occur, the memory size before and after collection, and the time required for collection. Turn on the-XX: + printgcdetails switch to learn more about GC changes. Turn on the-XX: + printgctimestamps switch to learn about the time of the garbage collection, measured in seconds after the JVM starts. Finally, you can use the-XX: + printheapatgc switch to learn more about the heap. To learn about the new domain, you can use the-XX: = printtenuringdistribution switch to get the object permission for the validity period.

6. Adjust the JVM of the PDM system

. SERVER: premise Memory 1 GB single CPU

You can adjust it by using the following parameters:-enable server mode on the server (if there are many CPUs, this option is recommended for servers)

-XMS and-xmx are generally set to the same size. 800 m

-Xmn sets newsize to the same as maxnewsize. 320 m

-XX: persize 64 m

-XX: newsize 320 m this value is set to a large adjustable new object area, reducing the number of full GC times

-XX: maxnewsize 320 m

-XX: The newrato newsize is not set. 4

-XX: Invalid vorratio 4

-XX: userparnewgc can be used to set parallel collection.

-XX: parallelgcthreads can be used to increase the degree of parallelism by 4.

-After xxuseparallelgc is set, you can clear the Collector in parallel.

-XX: useadaptivesizepolicy is better than the preceding one. It can be used to automatically optimize the new domain size and rescue space ratio.

. Client: Adjust the client JVM by setting parameters in the JNLP File

Parameters in JNLP: Initial-heap-size and max-heap-size

This parameter can be added when the JNLP file is generated in the requestmanager of the framework. However, these values must vary according to the client's hardware status (such as the client's memory size ). We recommend that you set these two parameters to 60% of the available memory of the client (to be tested ). In order to dynamically generate JNLP, the above two parameter values can vary with the client, reliably obtain the client system information and embed these values into the index. jsp of the home page as parameters for connection requests.

After the preceding parameters are set, you can use visualgc to observe the status of some garbage collection parameters and make corresponding adjustments to improve performance. The general standard is to reduce the number of fullgc times. It is recommended that the hardware support parallel garbage collection (requiring multiple CPUs ).