Sun JVM memory management and garbage collection

Memory Management and garbage collection are critical aspects of JVM. For Java performance analysis, it is very important to understand the basic memory management and garbage collection policies. This article describes Sun JVM 6.0 memory management and garbage collection.

1. Memory Management
During the program running, a large number of objects are created. Most of these objects are short-lived objects and a small part are long-lived objects. For short-lived objects, garbage collection needs to be performed frequently to ensure that useless objects are released as soon as possible. For long-period objects, garbage collection does not need to be performed frequently to ensure unnecessary garbage scanning and detection. To solve this problem, Sun JVM's memory management adopts a generational strategy.
1) Young GEN: the young generation mainly stores newly created objects. The memory size is relatively small and garbage collection is frequent. The young generation is divided into one Eden space and two suvivor spaces (named A and B)

When an object is created in the heap, it enters the Eden space of the young generation. During garbage collection, the garbage collector scans Eden space and a suvivor space. If the object persists, it is copied to B suvivor space. If B suvivor space is full, when the old Gen is copied to scan a suvivor space, if the object remains alive after several scans, and the JVM considers it as an old object, it is moved to the Old Gen. After scanning, the JVM clears the Eden space and a suvivor space, and then exchanges the roles A and B (that is, the Eden will be scanned next time the garbage collection is completed ).
Space and bsuvivor space.

We can see that the young Gen garbage collection method copies the surviving objects to the empty suvivor space to ensure that there are no memory fragments, and the Space-for-time method is used to accelerate the memory garbage collection.
2) tenured GEN: the old generation mainly stores objects that the JVM considers to be old (which still exists after several young Gen garbage collection times ), the memory size is relatively large, and garbage collection is relatively less frequent (for example, it may take several hours ). The old generation mainly uses compression to avoid Memory fragments (moving surviving objects to the side of the memory chip). Of course, some garbage collectors (such as CMS garbage collectors) are efficient, it may not be compressed.
3) perm GEN: the persistent generation mainly stores class definitions, bytecode, constants, and other information that is rarely changed, for details about the garbage collection policy, refer to my other blog Tomcat context reloadabled and outofmemory (permspace).
Class data sharing (CDS) (http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html) is a new feature introduced by jdk5. it shares some class definition information between virtual machines (Classes loaded by bootstrapclassloader) speed up JVM startup and memory usage. It is mainly used on the client. If you need to reset the class, it is best to disable CDs. (By default, CDs is disabled in JVM server mode and CDs is enabled in client mode)

-Xshare: Off
Disable class data sharing.
-Xshare: On
Require class data sharing to be enabled. If it cocould not be enabled for varous reasons, print an error message and exit.
-Xshare: Auto
The default; enable class data sharing whenever possible.

 

We can use the jconsole to view the display () of the above areas, from left to right: edenspace, A suvivor space, tenured Gen, code cache, Perm Gen (shared-wr) perm Gen (shared-Ro), Perm gen

2. Garbage Collection Policy
Two important measures for evaluating a garbage collection policy are:

Throughput: the longer the JVM spends on garbage collection, the lower the throughput (Pause Time): There is a pause period in the JVM garbage collection process, during the pause period, the application cannot run. The pause time is the length of the pause period.

Unfortunately, these two indicators usually conflict with each other. Improving one of them will affect the other. Depending on the scenario, we decide whether to prioritize throughput or pause time, for applications that require real-time response, we need to prioritize the pause time. For applications running in the background, we need to prioritize the throughput.
Before examining various garbage collectors, we need to understand several important strategies.

Parallel (parallel): Parallel indicates that multiple threads are used for garbage collection at the same time. This policy generally improves the pause time and throughput at the same time on servers with multiple CPU cores, this is basically the policy we want to use. Concurrent: parallelism indicates that some operations (such as spam) of the garbage collector are performed simultaneously with the application, which further shortens the pause time. Note that, at the same time, the complexity of the garbage collector will greatly increase, basically reducing the throughput. Memory Fragment processing: There are three policies: no compression, compression, and copy. In terms of space, copying will consume more memory (for example, the above memory-managed young Gen needs to maintain an additional suvivor space). In terms of time, non-compression reduces the memory allocation efficiency when creating objects. In the case of garbage collection, the copy policy is more efficient than the compression policy.

Sun JVM has 4 garbage collectors:

Serial COLLECTOR: sequence garbage collector. For both young Gen and tenured Gen, the garbage collector uses a single-line garbage collection method. For young Gen, the copy policy is used to avoid Memory fragments. For Old Gen, the compression policy is used to avoid Memory fragments. Basically, this method should be avoided on the kernel server. Enable serial collector using-XX: + useserialgc in JVM startup parameters.

Parallel COLLECTOR: Concurrent garbage collector. For both young Gen and tenured Gen, the garbage collector uses multi-thread parallel garbage collection. For young Gen, the copy policy is used to avoid Memory fragments. For Old Gen, the compression policy is used to avoid Memory fragments. Use-XX: + useparallelgc in JVM startup parameters to enable parallel collector.

Parallel compacting COLLECTOR: Parallel compression garbage collector, which is similar to parallel collector garbage collection, but uses a more effective garbage collection policy for tenured Gen, this garbage collector takes a Shorter pause time. Use-XX: + useparalleloldgc in JVM startup parameters to enable parallel compacting collector.

Concurrent mark-sweep (CMS) COLLECTOR: the concurrent mark clears the Garbage Collector. For young Gen, the same garbage collection policy as parallel collector is used for tenured Gen, the garbage collection mark thread and the application thread are executed at the same time, while the Application Thread needs to be paused for garbage removal, but the pause time will be greatly reduced. Note that because the garbage collection process is more complex, will reduce the overall throughput.