Four garbage collectors for j2se 5.0 hotspot

The following content is found in Sun's White Paper 1-. Due to my understanding, it is not a translation article (poor English, poor translation ). here, I only focus on the recycling abstraction mechanism, which is not involved in reference counting and specific algorithms.

Hotspot (j2se 5.0, also applies to 6.0 according to the White Paper) uses the so-called generational collection mechanism, which divides objects into young and old (and permanent, the young object will become an old object after several recycles (after a long time. this mechanism is used based on the following observation: Most new object references will not last long, that is, Die
Young; a small number of references will continue.

Therefore, young generation
There will be more collections, so the algorithm used has a high requirement on time efficiency.
Generation stores a large amount of data, and the Space-demanding efficiency of the algorithms used is relatively high. objects are divided into different generations to facilitate operations using different algorithms.

Correspondingly, the hotspotjvm memory can be divided into: Young
Generation, oldgeneration, and permanent generation. By default, all the objects are placed on the left of the region.

J2sehotspot JVM
In section 4, the garbage collector belongs to the generational collection.

Generally, when a new object is created, the memory is usually allocated in Young, old stores the surviving objects in young after several recycling times and some large objects allocated in old at the beginning. permanent
Generation stores class information and metadata.

Younggeneration is divided into an Eden region and two consumer vor
Region. The object is generated in the Eden region. After a GC, the surviving object enters the same vor, and then enters the old
. At the same time, only one vor region is saved, and the other is empty.

 

When the young region is full, the GC algorithm of the young region is executed. when the old and permanent regions are full, young GC is executed first. execute the GC of old and permanent. If too many objects in the old region cannot execute the GC of young, execute the GC algorithm of old in the young region (because the memory space is low ), however, the old algorithm of the CMS recycler does not work. The reasons are described below.

 

For multi-threaded applications, JVM
Use a thread-localallocation buffers to allocate objects to each thread in a region to eliminate thread competition. If this region is full, use the lock.

 

Four types of GC for hotspot
Recycler:

Serializable collection of serial COLLECTOR:

Feature: the application will be suspended during recycling.

Young region: copy the surviving objects in the Eden and a region vor region to another region vor region (set as to) (large objects are directly placed in the old region ). if the to region is full, copy it to the old region.

Old Region: Use the Mark-sweep-compact GC algorithm to mark the surviving object, clear the discarded object, and move all the surviving objects to a region, A large amount of free space is provided.

Applicability: Most client applications can use this collection algorithm, which is also the default collection algorithm of hotspot. it takes less than half a second to completely recycle a 64 MB area on the current machine.

 

Parallel collection of parallel COLLECTOR:

Features: multi-core CPU can be used.

Young region: the basic mechanism of suspending applications is similar to serialization, but multithreading can accelerate efficiency.

Old Region: Same serialization.

It can be used on multi-core computers.

 

Parallel compression and recovery parallel compacting COLLECTOR:

Compared with parallel collection, this mainly involves a new algorithm in the old area. At the same time, according to the White Paper, such collection will eventually replace parallel collection.

Young region: Parallel recovery.

Old region: first, we divide old into several consecutive regions. then, check in parallel in each region to mark the alive object (first mark the object that can be directly referenced, and then all ). then begin to check these areas, to obtain the degree of density (the area on the left is certainly more intensive than the area on the right), from a very dense area, parallel compression of the right area.

Applicability: for multi-core environments with pause time requirements, it is better to use parallel compression for recovery than parallel recovery. however, for servers with a high sharing rate (that is to say, one server runs multiple applications), GC of one application may affect other applications because the collection in the old region is slow and multithreading occurs. corresponding solution: You can configure to reduce the number of concurrent threads.

 

Parallel mark clearing recycle concurrent mark sweep COLLECTOR:

Young region: Parallel recovery.

The old region is divided into several steps.

Initialmark: When GC is required, the application is paused and all directly referenced objects are marked.

Concurrentmark: Then, continue the application and check the marked objects to get all the surviving objects.

Remark: Pause the application again, check (new, obsolete) the objects modified by the application during the concurrent mark duration, and mark the surviving objects. this phase lasts for a long time, so multithreading is used. after the stage ends, all the surviving objects are marked, and unmarked objects are junk objects.

Sweep: Stop the application and release the space of all junk objects.

 

Differences from other algorithms:

First, do not perform compression. However, some memory blocks will be merged/split by calculating potential memory requirements in the future.

Second, GC is not executed when the old area is full, but when the space is smaller than a certain degree.

Third: fragments are generated because compression is not performed.

In addition, CMS can also use the incremental running mode, that is, only part of the work is executed in the concurrentmark stage, and then the resources are returned to the application. the recycler is divided into several parts and arranged to be completed in the idle phase of the young area twice. this mode is generally used when the pause time is required and the number of processors is small (single-core or dual-core ).

In general, compared with parallel collection, CMS reduces the pause time of the old GC (sometimes the effect is significant) and slightly prolongs the young
GC time (because the time for objects to be transferred from the young area to the old area will be longer: no compression is performed, so you must first find the appropriate area), reducing the execution efficiency of the entire system, and greatly enhance the demand for memory space.

 

Applicable scope: there are requirements on the pause time, and the server can allocate some resources to the GC thread. Generally, it is applicable to applications with relatively large old
Generation, and it is a multi-core processor server. For example, web server (specifically Web Server)