The garbage collection mechanism of JVM and tuning _java programming

Article Source: matrix.org.cn Author: ginger547

GC Overview of 1.JVM

The GC, or garbage collection mechanism, is the memory that the JVM uses to free objects that are no longer in use. The Java language does not require the JVM to have a GC, nor does it specify how the GC works. However, the common JVM has a GC, and most GC uses a similar algorithm to manage memory and perform collection operations.

After fully understanding the garbage collection algorithm and the execution process, can effectively optimize its performance. Some garbage collection is dedicated to special applications. For example, live applications are primarily designed to avoid garbage collection outages, while most OLTP applications focus on overall efficiency. By understanding the workload of the application and the garbage collection algorithm supported by the JVM, you can configure the garbage collector optimally.

The purpose of garbage collection is to clear objects that are no longer in use. GC Determines whether an object is collected by determining whether it is referenced by the active object. The GC first has to determine whether the object is time to collect. Two common methods are reference counts and object reference traversal.

1.1. Reference Count
A reference count stores all the references to a particular object, that is, when an application creates a reference and the reference is out of range, the JVM must appropriately increase or decrease the number of references. When an object has a reference number of 0 o'clock, garbage collection can be done.

1.2. Object reference traversal
The early JVM used reference counting, and now most JVMs use object reference traversal. Object reference traversal determines the reachable (reachable) object, starting with a set of objects, and following each link along the entire object graph. If an object cannot arrive from one of these root objects (at least one), it is collected as garbage. In the object traversal phase, the GC must remember which objects are reachable so that the unreachable object is deleted, which is called a tag (marking) object.

Next, the GC removes unreachable objects. When deleted, some GC is just a simple scan stack, removing unmarked unmarked objects and freeing their memory to generate new objects, called scavenging (sweeping). The problem with this approach is that the memory is divided into small segments that are not sufficient for new objects, but are large in combination. As a result, many GC can rearrange objects in memory and compress (compact) to form available space.

To this end, the GC needs to stop other activity activities. This approach means that all application-related work stops and only the GC runs. As a result, many promiscuous requests were added or subtracted during the response. In addition, more complex GC increases or runs at the same time to reduce or eliminate application interruptions. Some GC use single-threaded to complete this work, while others use multithreading to increase efficiency.

2. Several garbage collection mechanisms

2.1. Mark-Purge collector
This collector first traverses the object graph and marks the reachable objects. The stack is then scanned to find unmarked objects and release their memory. This collector typically uses single-threaded work and stops other operations. The

2.2. Tag-Compression collector
is sometimes also called a mark-purge-compression collector, with the tag-purge collector having the same marking phase. In the second phase, the tagged object is copied to the new domain of the stack to compress the stack. This collector also stops other operations.

2.3. Replication Collector
This collector divides the stack into two domains, often called a half space. Using only half of the space each time, the new object generated by the JVM is placed in the other half of the space. When the GC runs, it compresses the stack by copying the reachable objects to the other half of the space. This approach applies to objects with short lifetimes, and continuous replication of long lifetime objects results in reduced efficiency. The

2.4. Incremental collector
Incremental collector divides the stack into multiple domains, collecting garbage from only one domain at a time. This can cause a smaller application outage.

2.5. Generational collector
This collector divides the stack into two or more domains to store objects of different lifetimes. New objects generated by the JVM are generally placed in one of the domains. Over time, the objects that continue to exist will get the usage period and go into a longer lifetime domain. The generational collector uses different algorithms for different domains to optimize performance. The

2.6. Concurrent collector
Concurrent collector runs concurrently with the application. These collectors generally have to stop other operations at some point, such as compression, to complete a specific task, but because other applications can do other background operations, the actual time to interrupt other processing is greatly reduced. The

2.7. Parallel collector
Parallel collector uses a traditional algorithm and uses multithreading to perform 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 primary domains: The new domain, the old domain, and the permanent domain. All new objects generated by the JVM are placed in the new domain. Once the object has experienced a certain amount of garbage collection loops, it gets the usage period and goes into the old domain. In a permanent domain, the JVM stores the class and method objects. In the case of configuration, a permanent domain is a stand-alone domain and is not considered part of the heap.

The following describes how to control the size of these fields. 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 128M:
java–xms128m
–xmx256m to control the size of the new domain, you can use-xx:newratio to set the proportions of the new domain in the heap.

The following command sets the entire heap to 128m, and the new domain ratio is set to 3, that is, the new domain is 1:3 of the old domain, and the new domain is 1/4 or 32M of the heap:
java–xms128m–xmx128m
–xx:newratio =3 can set the initial and maximum values of the new domain using-xx:newsize and-xx:maxnewsize.

The following command sets the initial and maximum values for the new domain to 64m:
java–xms256m–xmx256m–xmn64m
The permanent domain default size is 4m. When you run the program, the JVM adjusts the size of the permanent domain to meet your needs. Each time the adjustment is made, the JVM makes a complete garbage collection of the heap.

Use the-XX:MAXPERSIZE flag to increase the permanent domain lap size. When a WebLogic server application loads more classes, it is often necessary to increase the maximum value of the permanent domain. When the JVM loads the class, the objects in the permanent domain increase dramatically, causing the JVM to constantly resize the permanent domain. To avoid adjustments, use the-XX:PERSIZE flag to set the initial value.

The following sets the permanent domain initial value to 32m and the maximum value is set to 64m.
java-xms512m-xmx512m-xmn128m-xx:permsize=32m-xx:maxpermsize=64m

By default, hotspot uses the replication collector in the new domain. The 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, copies all reachable objects to the current from relief space, and once the current from relief space is full, the collector copies the reachable objects to the current to save space. From and to relief space interchange roles. The active objects will continue to replicate in the salvage space until they are used and transferred to the old domain. Use-xx:survivorratio to control the size of the new domain subspace.

Like Newration, the Survivorration stipulates the ratio of a rescue domain to the Eden space. For example, the following command sets the new domain to 64m,eden for 32m, each of which accounts for 16m:
Java-xms256m-xmx256m-xmn64m-xx:survivorration =2

As mentioned previously, hotspot uses a copy collector for the new domain by default, and a mark-purge-compress collector for the old domain. Using a replication collector in a new domain has many implications, because most of the objects that the application generates are short-lived. Ideally, all transition objects will be collected when they move out of Eden space. If so, and the objects that move out of the Eden space are long-lived, they can theoretically be moved immediately to the old domain, avoiding repeated duplication in the rescue space. However, applications cannot fit this ideal state because they have a small number of long-lived objects. It is best to keep these long-lived objects and put them in a new domain because copying a small number of objects is always cheaper than compressing the old domain. To control the replication of objects in the new domain, you can use-xx:targetsurvivorratio to control the proportion of the rescue space (this value is to set the usage ratio of the salvage space.) such as the rescue space bit 1M, the value of 50 indicates available 500K). The 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 better exploit the rescue space. The upper limit can be controlled with-xx:maxtenuring threshold.

The maxtenuring threshold can be set to 0 to place all of the replication occurrences and to expect the object to extend from Eden to the old domain. After the setup is complete, the rescue space is no longer in effect, so the survivorratio should be set to the maximum value to maximize Eden space, set as follows:
Java ...-xx:maxtenuringthreshold=0–xx:survivorratio=50000 ...

use of the 4.BEA JRockit JVM
The new JVM used by Bea WebLogic 8.1 is used on the Intel platform. A folder similar to jrockit81sp1_141_03 can be seen in the BEA installed directory. This is the directory where Bea's new JVM resides. Unlike hotspot, which compiles Java bytecode to a cost code, it is precompiled into a class. JRockit also provides more granular functionality to observe the running state of the JVM, primarily a stand-alone GUI console (only for use with JRockit to use jrockit81sp1_141_ 03 the console is monitored with some CPU and memory parameters, or the WebLogic Server console.

The Bea JRockit JVM supports 4 kinds of garbage collectors:
　　 4.1.1. Generational replication Collector
This is similar to the default generational collector work policy. Objects are allocated in the new domain, that is, the nursery in the JRockit document. This collector is best suited for small heap operations on single CPU machines.

　　 4.1.2. Single Space concurrent collector
The collector uses the full heap and works with the background thread. Although this collector eliminates interruptions, the collector takes a long time to find dead objects and the collector often runs when the application is processed. If the processor cannot cope with the garbage generated by the application, it interrupts the application and closes the collection.

Generational concurrent collectors This collector uses the exclusive replication collector in the care domain and the concurrent collector in the old domain. Because it is more frequent than a single space collector interrupt, it requires less memory and the application is running more efficiently, noting that too little care can cause a large number of temporary objects to be extended to the old domain. This can result in the collector being overloaded, and even in the way of exclusive working to complete the collection.

　　 4.1.3. Parallel collector
The collector also stops the work of other processes, but uses multithreading to speed up the collection process. Although it is more likely to cause a long interruption than other collectors, it generally makes better use of memory and has a higher efficiency.

By default, JRockit uses the generational concurrency collector. To change the collector, you can use-XGC: , the corresponding four collectors are gencopy,singlecon,gencon and parallel respectively. You can use-XMS and-xmx to set the initial size and maximum value of the heap. To set up the care domain, use the-xns:java–jrockit–xms512m–xmx512m–xgc:gencon–xns128m ... Although the JRockit supports the-VERBOSE:GC switch, the information it outputs will vary depending on the collector. The JRockit also supports memory, load, and codegen output.

Note: If you use the JRockit JVM, you can also use the WLS Console (C:\bea\jrockit81sp1_141_03\bin) to monitor some data, such as Cpu,memery. To be able to construct the monitor must add the-xmanagement parameter in the Startweblogic.cmd when the service is started.

5. How to get information from the JVM to make adjustments

The-VERBOSE.GC switch can display the contents of the GC. Opens it to show when the busiest and most idle collection behavior occurs, the amount of memory before and after the collection, and the time it takes to collect. Open the-xx:+ printgcdetails switch to learn more about the changes in the GC. Open the-XX: + printgctimestamps switch to find out when these garbage collections occur, measured in seconds since the JVM started. Finally, the-XX: + PRINTHEAPATGC Switch to learn more detailed information about the heap. In order to understand the situation of the new domain, you can use the-xx:=printtenuringdistribution switch to understand the object rights for the usage period.

6.PDM System JVM Tuning

　　 6.1. Server: Prerequisite memory 1G Single CPU

You can adjust by using the following parameters:-server Enable server mode (if the CPU is more, the server machine recommends this)

-xms,-xmx are generally set to the same size. 800m
-XMN is to set the newsize and Maxnewsize as the same. 320m
-xx:persize 64m
-xx:newsize 320m This value is set to large adjustable Daxin object area, reducing full GC times
-xx:maxnewsize 320m
The-xx:newrato newsize is not set. 4
-xx:survivorratio 4
-XX:USERPARNEWGC can be used to set up parallel collections
-xx:parallelgcthreads can be used to increase the degree of parallelism 4
-XXUSEPARALLELGC You can use the parallel purge collector after setting
-xx:useadaptivesizepolicy is better with a combination of the above, it can automatically optimize the new domain size and save space ratio

　　 6.2. Client: Adjust the client JVM by setting parameters in the Jnlp file

JNLP parameters: Initial-heap-size and Max-heap-size

This can be added when generating JNLP files in the framework's requestmanager, but these values require changes based on the client's hardware state (such as the size of the client's memory). It is recommended that these two parameter values be set to 60% of the available memory for the client (pending testing). In order to dynamically generate JNLP, the above two parameter values can vary with the client, and reliable consideration is given to obtaining the client system Information and embedding these in the home index.jsp as a connection request parameter.

After setting the above parameters, we can observe some parameter states of garbage collection by VISUALGC, then make corresponding adjustment to improve the performance. The general standard is to reduce the number of FULLGC, with the best hardware support using parallel garbage collection (requiring multiple CPUs).