Deep understanding of Java 5.0 Garbage collection

Memory management is an important factor that affects the performance of software applications. Allocating and unloading memory takes longer than the actual data calculation time.

Although C + + can directly control memory allocation and release, Java uses garbage collection to reclaim memory that the program no longer needs, trying to master memory management. However, when real-time performance is needed, the "pause" associated with garbage collection has always been a central point of opposition to the response to Java.

Garbage collection is a cyclical process that interrupts the normal execution of programs, analyzes object references, and reclaims memory that is allocated but no longer referenced. In large Java applications, garbage collection pauses can last a few seconds, enough to interrupt any type of real-time communication or control system.

Therefore, the memory extraction provided by garbage collection requires some developers to think more carefully about memory management issues. Even if Java does not provide the same level of memory allocation control as C + +, programming patterns can still have a significant impact on the memory performance of Java applications.

In this article, I'll briefly review the garbage collection tuning feature of Java 5.0.

Java 5.0 Garbage Collection principle

Java 1.5 new features?? Ergonomics?? The goal is to provide the JVM with excellent performance with minimal command-line tuning. Ergonomics attempts to select the best garbage collector, heap size, and Run-time compiler for an application.

When does the choice of garbage collector affect users? For many applications, it has no effect at all. That is, applications can execute within their specifications when the frequency of pauses generated by garbage collection and the duration is moderate. An exception occurs when a large application expands to produce a large number of threads, processors, sockets, and many memory.

If an object can no longer be reached by running any of the pointers in the program, it is considered garbage. The most direct garbage collection algorithms simply iterate over each reachable object. Then, the rest of the object is rubbish. The time spent in this method is proportional to the number of active objects and prevents large applications that maintain many of the active data.

Starting with Java 2, virtual machines combine a variety of collection algorithms that use generational collection combinations. Although the simple garbage collection examines each active object in the heap, the generational collection utilizes several empirical observations of most applications to avoid additional work. One of the most important features of these observations is the so-called early failure rate. Many objects were assigned soon after "dead". For example, an iterator object survives only in a separate loop. To optimize this situation, we manage the memory in a generational, or preserve objects of different ages in the memory pool. When a generation fills up, the generation is garbage collected. Objects are assigned to a more age object generation, or Cenozoic. Due to early failure, most of the objects died there.

If the garbage collector becomes a bottleneck, you may want to customize the size of the generation. Examine the output of the garbage collector in detail, and then explore the sensitivity of the individual performance units to the garbage collector parameters.

When initialized, retains one of the largest address spaces and is allocated to physical memory when necessary. The entire address space reserved for object memory can be divided into cenozoic and old generations. The new generation consists of Eden and two living spaces. The object was initially assigned to Eden. At any time, a living space is empty and as the destination of the next space, a collection of active objects is replicated in Eden and another living space. Objects are replicated in the living space in this way until they are aged, or copied into the old generation. The third generation, which is closely related to the old generation, is called the eternal generation. This is a special generation because it preserves the data required by the virtual machines to describe objects that have no equivalents in the Java language. For example, objects that describe classes and methods are stored in an immortal generation.

Performance factors

Java applications, especially garbage collection, have two units of performance measurement: throughput and pause. Throughput is the percentage of time that has not been used for garbage collection for a longer period of time. Throughput includes the time allocated for allocation (but the time used to adjust the allocation speed is generally not included). Pausing is the pause time that an application appears due to garbage collection.

Some users are also more sensitive to other factors. For example, occupancy rate (footprint) is a collection of worker processes, measured in page and buffer rows, that can represent extensibility in systems with limited physical memory or many processes.

Reactivity (promptness) is the time lag when the object dies and the memory becomes available, and is an important factor in the distribution system, including the remote method call (RMI).

Typically, a particular surrogate size chooses the balancing effect of these factors. For example, a very large Cenozoic can have the largest throughput, but at the expense of occupancy, responsiveness, and pause times. You can also sacrifice throughput, using a small cenozoic to make the Cenozoic pause for the shortest time.

If you want to improve the performance of an application with a large number of processors, you should use the throughput collector. You can activate the throughput collector using the command line tag-XX:+USEPARALLELGC. You can control the number of garbage collector threads using the parallelgcthreads option-xx:parallelgcthreads=.

The maximum pause time target is specified with the command line tag-xx:maxgcpausemillis=, which is a hint to the throughput collector that it requires milliseconds or shorter pause times. There are many options for resizing, such as-xx:younggenerationsizeincrement= for the Cenozoic, and-xx:tenuredgenerationsizeincrement= for the old generation.

If your application benefits from a shorter garbage collector pause and is able to share processor resources with the garbage collector while the application is running, I recommend that you use a parallel low pause collector. If the old generation occupancy rate exceeds the initial occupancy rate (that is, the percentage of the current heap is used before the concurrent collection starts), the concurrent collection starts.

The default initial occupancy rate is about 68%. You can set it with the parameter-xx:cmsinitiatingoccupancyfraction=, which is the current old generation size percentage. You can use concurrent collectors in a way that is incrementally completed in the concurrency phase. This pattern (called "i-cms" here) divides the work performed by the collector into a small segment of time, arranged between the Cenozoic collections. This feature is useful when an application that requires a short pause time from the concurrent collector is running on a machine with a small number of processors.