The JVM's garbage collection mechanism for detailed understanding and tuning

The JVM's garbage collection mechanism for detailed understanding and tuning

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

GC Overview for 1.JVM

A GC is a garbage collection mechanism that is used by the JVM to free memory that is consumed by objects that are no longer in use. The Java language does not require the JVM to have a GC, nor does it stipulate how the GC works. However, the common JVM has 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, it can effectively optimize its performance. Some garbage collection is dedicated to special applications. For example, real-time applications are primarily designed to avoid garbage collection outages, while most OLTP applications focus on overall efficiency. With an understanding of the workload of the application and the garbage collection algorithms supported by the JVM, the garbage collector can be optimally configured.

The purpose of garbage collection is to clear objects that are no longer in use. The GC determines whether to collect the object by determining whether the object is referenced by the active object. The GC first determines whether the object is ready to be collected. Two common methods are reference counts and object reference traversal.

1.1. Reference counting

The reference count stores all references to a particular object, that is, when the application creates a reference and the reference goes out of scope, the JVM must increase or decrease the number of references appropriately. When an object has a reference count of 0 o'clock, garbage collection is possible.

1.2. Object reference traversal

Earlier JVMs used reference counting, and most JVMs now traverse with object references. Object reference traversal starts with a set of objects and recursively determines the reachable (reachable) object along each link on the entire object graph. If an object cannot arrive from one (at least one) of these root objects, it is garbage collected. During the object traversal phase, the GC must remember which objects can be reached in order to delete the Unreachable object, which is known as the markup (marking) object.

Next, the GC wants to delete the unreachable object. When deleted, some GC simply scans the stack, removes unmarked unmarked objects, and frees their memory to generate new objects, called Purge (sweeping). The problem with this approach is that memory is broken into small chunks, which are not sufficient for new objects, but are very large in combination. As a result, many GCs can reorganize objects in memory and compress (compact) to make available space.

To do this, the GC needs to stop other active activities. This approach means that all application-related work is stopped and only the GC is running. As a result, many miscellaneous requests are added and subtracted during the response. In addition, more complex GCS are constantly increasing or running concurrently to reduce or eliminate the interruption of the application. Some GC uses a single thread to do the work, while others use multithreading to increase efficiency.

2. Several garbage collection mechanisms

2.1. Mark-Clear Collector

The collector first loops through the object graph and marks the reachable objects, then scans the stack for unmarked objects and frees up their memory. This collector typically uses a single thread to work and stops other operations.

2.2. Tag-Compression collector

Sometimes also called Mark-purge-compress collector, with the mark-purge collector has the same marking stage. 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 Collector

This collector divides the stack into two domains, often referred to as half-space. Using only half of the space at a 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 object to the other half of the space. This method is suitable for short-lived objects, and continuous replication of long-lived objects results in reduced efficiency.

2.4. Incremental collector

The incremental collector divides the stack into multiple domains, collecting garbage from only one domain at a time. This can result in a smaller application outage.

2.5. Generational Collectors

This collector divides the stack into two or more domains for storing objects of different lifetimes. A new object generated by the JVM is typically placed in one of the domains. Over time, objects that continue to exist will receive a lifetime and go into a longer-lived domain. The generational collector uses different algorithms for different domains to optimize performance.

2.6. Concurrent Collector

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

2.7. Parallel collector

The parallel collector uses some traditional algorithms and uses multithreading to perform their work in parallel. The use of multithreading on multi-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 a generational collector, which divides the heap into three main domains: new, old, and permanent. All new objects generated by the JVM are placed in the new domain. Once an object undergoes a certain number 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 terms of configuration, a permanent domain is a separate 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 entire heap's original size or maximum value.

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 percentage of the new domain in the heap.

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

Java–xms128m–xmx128m–xx:newratio =3 can use-xx:newsize and-xx:maxnewsize to set the initial and maximum values for the new domain.

The following command sets the initial and maximum values of the new domain to 64m:

java–xms256m–xmx256m–xmn64m

The default size of the permanent domain is 4m. When you run the program, the JVM adjusts the size of the permanent domain to suit your needs. Each time the adjustment is made, the JVM performs a full garbage collection of the heap.

Use the-XX:MAXPERSIZE flag to increase the size of the permanent domain. When the WebLogic server application loads more classes, it is often necessary to increase the maximum value of the persistent domain. When the JVM loads a class, objects in the permanent domain increase sharply, allowing the JVM to constantly adjust the permanent domain size. 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 to 64m.

java-xms512m-xmx512m-xmn128m-xx:permsize=32m-xx:maxpermsize=64m

By default, hotspot uses the replication collector in the new domain. This field is generally divided into three parts. The first part is Eden, which is used to generate new objects. The other two are called rescue spaces, and when Eden is full, the collector stops the application, copies all reachable objects to the current from rescue space, and once the current from rescue space is filled, the collector copies the reachable objects to the current to rescue space. From and to rescue space swap roles. The active objects will continue to replicate in the rescue space until they have been used and transferred to the old domain. Use-xx:survivorratio to control the size of new domain sub-spaces.

As with Newration, Survivorration prescribes the ratio of a rescue area to Eden space. For example, the following command sets the new domain to 64m,eden of 32m, each of which occupies 16m:

Java-xms256m-xmx256m-xmn64m-xx:survivorration =2

As mentioned earlier, the hotspot uses the replication collector for the new domain by default, and uses the tag-purge-compress collector for the old domain. Using the replication collector in a new domain has a lot of meaning, because most of the objects that the application generates are short-lived. Ideally, all transition objects will be collected when they are moved out of Eden Space. If this is the case, and the objects that move out of the Eden space are long-lived, you can theoretically move them into the old domain immediately, avoiding repeated duplication in the rescue space. However, applications do not fit into this ideal state because they have a small percentage of objects that are long-lived. It is best to keep these long-lived objects in the new domain, because copying a small portion 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:targetsurvivorratio to control the proportions of the rescue space (the value is the usage ratio for setting up the rescue space. If the salvage space is 1M, the value 50 indicates available 500K). The value is a percentage, and the default value is 50. When the larger stack uses a lower sruvivorratio, the value should be increased to 80 to 90 to make better use of the rescue space. The upper limit can be controlled with-xx:maxtenuring threshold.

To place all replication occurrences and to extend the object from Eden to the old domain, you can put the maxtenuring Threshold is set to 0. After the setup is complete, the rescue space is not actually used, 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 Bea WebLogic 8.1 uses a new JVM for the Intel platform. A folder similar to jrockit81sp1_141_03 can be seen in the list of BEA installations. This is the directory where Bea new JVM resides. Unlike hotspot, which compiles Java bytecode into code, it is pre-compiled into classes. JRockit also provides more granular functionality to observe the operating state of the JVM, primarily a standalone GUI console (only available for use with JRockit jrockit81sp1_141_ The 03 console monitors some CPU and memory parameters) or the WebLogic Server console.

The Bea JRockit JVM supports 4 types of garbage collectors:

4.1.1. Generational replication Collector

It is similar to the default generational collector working policy. The JRockit object is assigned in the new domain, which is the nursery in the 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 can eliminate interrupts, collectors take a long time to find dead objects, and the collector often runs when the application is processed. If the processor is unable to cope with the garbage generated by the application, it interrupts the application and closes the collection.

Generational concurrency collector This collector uses the exclusive copy 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 a small care domain can cause a large number of temporary objects to be extended to the old domain. This can cause the collector to become overloaded and even perform the collection in an exclusive way of working.

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 prone to long interruptions than other collectors, it generally makes better use of memory and has higher program efficiency.

By default, JRockit uses a generational concurrency collector. To change the collector, the-XGC:<GC_NAME> can be used, and 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 a heap. To set up a care domain, use the-xns:java–jrockit–xms512m–xmx512m–xgc:gencon–xns128m ... Although the JRockit supports the-VERBOSE:GC switch, the information it outputs differs depending on the collector. The JRockit also supports the output of memory, load, and CodeGen.

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

5. How to obtain information from the JVM for tuning

The-VERBOSE.GC switch displays the operation contents of the GC. Open it to show when the busiest and most idle collection behavior occurred, the amount of memory before and after collection, the time it took to collect, and so on. Open the-xx:+ printgcdetails switch to learn more about the changes in the GC. Open the-XX: + printgctimestamps switch to see when these garbage collections occur, measured in seconds since the JVM started. Finally, more detailed information about the heap is learned through the-XX: + PRINTHEAPATGC switch. 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: Premise memory 1G single CPU

This can be adjusted by using the following parameters:-server Enable server mode (this is recommended for server machines if there are more CPUs)

-xms,-xmx are generally set to the same size. 800m

-XMN is to set newsize and Maxnewsize as the same. 320m

-xx:persize 64m

-xx:newsize 320m This value is set to a large adjustable Da object area, reducing the number of full GC

-xx:maxnewsize 320m

-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 works better with the previous one, and it can automatically optimize the new domain size and save space ratios

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

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

This adds the above parameters when generating the JNLP file in the framework's requestmanager, but these values are required to vary depending on the client's hardware state (such as the client's memory size, etc.). It is recommended that the two parameter values be set to 60% of the available memory for the client (to be tested). In order to dynamically generate JNLP, the above two parameter values can vary with the client, reliably taking the client system information and embedding these into the first page index.jsp as the parameters of the connection request.

After setting the above parameters, the VISUALGC can be used to observe some parameter states of garbage collection, and then make corresponding adjustments to improve performance. The general standard is to reduce the number of FULLGC, preferably hardware support using parallel garbage collection (requires multi-CPU).

The JVM's garbage collection mechanism for detailed understanding and tuning