Shulou(Shulou.com)06/03 Report--

What this article shares with you is about how to understand the JVM garbage collection strategy in the JVM1.4.1 version. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

We analyzed the classic JVM garbage collection techniques such as reference counting, copying, mark-clear, and mark-clean. Each of these methods has its own advantages and disadvantages under specific conditions. The technology used by JVM1.2 and later versions is called generational JVM garbage collection (generationalgarbagecollection), which combines the two technologies to combine the strengths of the two, resulting in very low object allocation overhead.

Garbage collection in JVM1.4.1

We analyzed the classic JVM garbage collection techniques such as reference counting, copying, mark-clear, and mark-clean. Each of these methods has its own advantages and disadvantages under specific conditions. For example, copying can do well when many objects become garbage, but it becomes bad when there are many long-lived objects (to copy them over and over again). On the contrary, tag-collation can do well for long-lived objects (copied only once), but not so good when there are many short-lived objects. The technology used by JVM1.2 and later versions is called generational JVM garbage collection (generationalgarbagecollection), which combines the two technologies to combine the strengths of the two, resulting in very low object allocation overhead.

Old object and young object

In any application heap, some objects become garbage soon after they are created, while others survive throughout the run of the program. Empirical analysis shows that for most object-oriented languages, including the Java language, the vast majority of objects-- up to 98% (depending on your measure of young objects)-- die young. The lifetime of an object can be calculated by the number of seconds of the clock, the total number of bytes allocated by the memory management subsystem after the object allocation, or the number of JVM garbage collections experienced after the object allocation. But no matter how you measure it, the analysis shows the same thing-most objects die at a young age. The fact that most objects die young makes sense for the choice of collectors. In particular, copy collectors perform fairly well when most objects die young, because copy collectors do not access dead objects at all; they just copy living objects to another heap area. and then reclaim all the remaining space at once.

Most of the objects that can survive through JVM garbage collection will become long-lived or * * objects. Depending on the mixing ratio of short-lived objects and long-lived objects, the performance of different JVM garbage collection strategies will vary greatly. Copy collectors work well when most objects die young, because objects that die when they are young never need to be copied. However, the copy collector handles long-lived objects badly, copying them back and forth repeatedly from one half-space to another. On the contrary, the tag-collation collector works well for long-lived objects, because long-lived objects tend to sink at the bottom of the heap so that they no longer have to be copied. However, mark-clear and mark-sort collectors do a lot of extra work to analyze dead objects because they have to analyze every object in the heap during the cleanup phase.

Generational collection

The generational collector (generializationalcollector) divides the heap into multiple generations. Objects created in the younger generation that meet certain promotion criteria, such as those that have experienced a certain number of JVM garbage collection, will be promoted to the next older generation. Generational collectors are free to use different collection strategies for different generations and carry out JVM garbage collection for each generation.

Small collection

One of the advantages of generational collection is that it does not collect all generations at the same time, so it can make JVM garbage collection pauses shorter. When the allocator cannot satisfy the allocation request, it first triggers a small minorcollection, which collects only the youngest generation. Because many objects in the younger generation are dead, the copy collector does not have to analyze dead objects at all, so small collection pauses can be quite short and usually reclaim a large amount of heap space. If the small collection frees up enough heap space, the user program can recover immediately. If it cannot free up enough heap space, it continues to collect the previous generation until enough memory is reclaimed. When the JVM garbage collector cannot reclaim enough memory after all collection, it will expand the heap or throw an OutOfMemoryError.

Intergenerational citation

Tracking JVM garbage collectors, such as copy, mark-clear, and mark-clean JVM garbage collectors, scan from the rootset, traversing references between objects until all living objects are accessed.

The generational trace collector starts with the root set, but does not traverse references to objects in the older generation, which reduces the size of the object graph to be tracked. But this also raises a problem-what if an object in the older generation references a younger object that cannot be reached through all other reference chains starting from the root?

To solve this problem, generational collectors must explicitly track references from old to young objects and add these old-to-young references to the root set of small collections. There are two ways to create references from old objects to young objects. Either modify the references contained in the old object to point to the young object, or promote the young object that references other young objects to an older generation.

Track intergenerational references

Whether an old-to-young reference is created by promotion or pointer modification, the JVM garbage collector needs all old-to-young references for small collections. One way to do this is to track the older generation, but this is obviously costly. A better way is to linearly scan the old generation to find references to young objects. This approach is faster and has a better locality than tracing, but it still requires a lot of work.

The assignment function (mutator) and the JVM garbage collector can work together to maintain a complete list of old-to-young references. When objects are promoted to an older generation, the JVM garbage collector can record all old-to-young references created as a result of this promotion, so that only intergenerational references created by pointer modifications need to be tracked.

The JVM garbage collector has several ways to track references that are too old to be young as a result of modifying references in existing objects. It can track them in the same way that reference counts are maintained in the reference count collector (the compiler can generate additional instructions around pointer assignments), or it can use virtual memory protection on the older generation heap to capture writes to older objects. Another potentially more efficient method of virtual memory is to use the page modification dirty bit (pagemodificationdirtybit) in the older generation heap to determine the block to scan when an object containing an old to young pointer is found.

With a few tricks, you can avoid the overhead of tracking each pointer change and checking whether it crosses generation boundaries. For example, there is no need to track storage for local or static variables because they are already part of the root set. You can also avoid tracking pointers stored in constructors that are only used to initialize fields of newly created objects (so-called initialization stores (initializingstores)), because (almost) all objects are allocated to the younger generation. In any case, the runtime must maintain a set of references from old objects to young objects and add those references to the root set when collecting the younger generation.

In figure 1, the arrows represent references between objects in the heap. The red arrow indicates an old to young reference that must be added to the root set for use by small collections. The blue arrow indicates references from the root set or the younger generation to the old object, and there is no need to track them when only the younger generation is collected.

Card mark

SunJDK uses an improved algorithm called the card marking (cardmarking) algorithm to identify changes to pointers contained in the fields of older generation objects. In this method, the stack is divided into a set of cards, each of which is generally smaller than one memory page. JVM maintains a card map that corresponds to a bit (a byte in some implementations) for each card in the heap. Each time a pointer field in an object in the heap is modified, the corresponding bit corresponding to that card is set in the card map. During JVM garbage collection, the tag bits associated with cards in the older generation are checked and dirty cards are scanned for objects that are referenced to the younger generation. Then clear the mark bit. Card tagging has several overhead-- the extra space required for card mapping, the extra work done on each pointer store, and the extra work done during JVM garbage collection. For each non-initialized heap pointer storage, the card marking algorithm can add only two or three machine instructions and require all dirty cards to be scanned during a small collection.

JDK1.4.1 default collector

By default, JDK1.4.1 divides the heap into two parts, a young generation and an old generation (in fact, there is a third part, the * space, which stores loaded classes and method objects). With the help of the copy collector, the young generation is divided into a creation space (often called Eden) and two survival half-spaces.

Older generations use mark-and-organize collectors. The object is promoted to the old generation after several copies. Small collections copy living objects from Eden and one survival half-space to another, and may promote some objects to the older generation. Big majorcollection collects both the younger generation and the older generation. The System.gc () method always triggers a large collection, which is one of the reasons why System.gc () should be used as little as possible, if not at all, because large collections take much longer than small collections. There is no way to programmatically trigger small collections.

Other collection options

In addition to the replication collector and tag-collation collector used by default, JDK1.4.1 includes four other JVM garbage collection algorithms, each for a different purpose. JDK1.4.1 includes an incremental collector (which has been around since JDK1.2) and three new collectors for more efficient collection in multiprocessor systems-parallel replication collectors, parallel cleanup (scavenging) collectors, and concurrent mark-clean collectors. These new collectors are designed to solve the problem that the JVM garbage collector has become a scalability bottleneck in multiprocessor systems. Figure 2 shows guidance on when to select an alternate collection option.

Incremental collection

The incremental collection option has been part of JDK since 1. 2. Incremental collection reduces JVM garbage collection pauses at the expense of throughput, which makes it worth considering only when shorter collection pauses are important, such as near-real-time systems.

The Train algorithm is an algorithm used by JDK for incremental collection that creates a new region between the older and younger generations of the heap. These heap areas are divided into "train", and each train is divided into a series of "car". Each car can be collected separately. As a result, each train car forms a separate generation, which means tracking not only references from old to young, but also from old trains to young trains and from old cars to young ones. This brings a lot of extra work to the assignment function (mutator) and the JVM garbage collector, but allows for a shorter collection pause.

Parallel collector and concurrent collector

The new collectors in JDK1.4.1 are designed to solve the problem of JVM garbage collector in multiprocessor systems. Because most JVM garbage collection algorithms stop the system for a period of time, a single-threaded collector can quickly become a scalability bottleneck, because when the JVM garbage collector suspends the user program thread, all but one processor is idle. Two of the new collectors-- the parallel replication collector and the concurrent mark-clear collector-- are designed to reduce collection pause time. The other is the parallel cleanup collector, which is designed for higher throughput on large heaps.

The parallel replication collector, enabled with the JVM option-XX:+UseParNewGC, is a young generation replication collector that divides the work of JVM garbage collection into as many threads as CPU. The concurrent mark-clear collector, enabled by the-XX:+UseConcMarkSweepGC option, is an old-generation mark-clear collector that temporarily stops the entire system during the initial marking phase (and later temporary relabeling phase), then resumes the user program, while the JVM garbage collector thread executes concurrently with the user program. The parallel copy collector and the concurrent mark-clear collector are basically concurrent versions of the default copy collector and mark-clean collector. The parallel cleanup collector enabled by-XX:+UseParallelGC is a younger generation collector optimized for very large (gigabyte and larger) heaps on multiprocessor systems.

Choose an algorithm

There are six algorithms to choose from, and you may not know which one to use. Figure 2 provides some guidance on dividing collectors into single-threaded and concurrent, and into short pauses and high throughput. As long as you have information about the application and the deployment environment, it is enough to choose the right algorithm. For many applications, the default collector works fine-- so if you don't have a performance problem, there's no need to add more complexity. However, if your application is deployed on a multiprocessor system or uses a very large heap, changing the collector options can lead to significant performance gains.

Fine-tune the JVM garbage collector

JDK1.4.1 also includes a number of options for fine-tuning JVM garbage collection. Adjusting these options and measuring their effectiveness can take a lot of time, so thoroughly profile and optimize your application before trying to fine-tune the JVM garbage collector, so your fine-tuning work may get better results.

The first thing to do to fine-tune JVM garbage collection is to examine the lengthy GC output. This gives you information about the frequency, timing, and duration of JVM garbage collection operations. The simplest JVM garbage collection fine-tuning is to increase the size of the heap (- Xmx). As the heap grows, replication collection becomes more efficient, so when you increase the heap, you reduce the collection cost per object. In addition to increasing the size of the heap, you can also use the option-XX:NewRatio to increase the share of space allocated to the younger generation. You can also explicitly specify the size of the younger generation with the-Xmn option.

As JVM evolves, the default JVM garbage collector gets better and better. The generational JVM garbage collector used by JDK1.2 and later provides much better allocation and collection performance than the mark-clean-clean collector used by earlier JDK. JDK1.4.1 further improves the efficiency of JVM garbage collection by adding new multithreaded collection options for multiprocessor systems and very large heaps.

The above is how to understand the JVM garbage collection strategy in the JVM1.4.1 version. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.