In the above

☕ “Moonlight Box” [JVM Technical Guide] “JVM Summary Notes” Java Virtual Machine garbage collection awareness and tuning “Sinan” [top]

Parallel collector

A parallel collector (also known as a throughput collector) is a generational collector similar to a serial collector. The main difference between the serial and parallel collectors is that the parallel collector has multiple threads to speed up garbage collection.

Through command line options-XX:+UseParallelGCEnable the parallel collector. By default, with this option, both minor and Major GCS are run in parallel to further reduce garbage collection overhead.

Number of parallel garbage collector threads

Command line options are available-XX:ParallelGCThreads=<N>Controls the number of garbage collector threads.

An arrangement of generations in a parallel collector

In a parallel collector, the generations are arranged differently.

Parallel Collector Ergonomics tuning

When selecting a parallel collector with -xx :+UseParallelGC, it supports automatic tuning methods that allow you to specify behavior rather than generational sizes and other low-level tuning details.

Options to specify the behavior of the parallel collector

  • Maximum garbage collection pause time: use the command line option-XX:MaxGCPauseMillis=<N>Specify a maximum pause time target, which is interpreted as requiring a pause time of milliseconds or less; By default, there is no maximum pause time target.

  • If a pause time target is specified, the heap size and other parameters related to garbage collection are adjusted to make the garbage collection pause time shorter than the specified value.

  • The desired pause time goal may not always be achieved.

These adjustments can cause the garbage collector to reduce the overall throughput of the application.

throughput

Throughput goals are measured in terms of the time spent performing garbage collection versus the time spent outside of garbage collection (called application time). The target is specified by the command line option -xx :GCTimeRatio=, which sets the ratio of garbage collection time to application time to 1 / (1 + N).

  • For example, -xx :GCTimeRatio=19 sets the goal of garbage collection at 1/20 or 5% of the total time. The default value is 99, resulting in a target garbage collection time of 1%.
Memory space

In addition to specifying the maximum heap footprint with the option -xmx, the collector has an implicit goal of minimizing the size of the heap while meeting other goals.

Priority of the parallel collector target

The goals are the maximum pause time goal, throughput goal, and minimum footprint goal, which are achieved in this order:

  • Achieve the maximum pause time goal first. Only after this requirement is met can the throughput target be achieved. Again, the memory size goal is considered only after the first two goals have been achieved.

The parallel collector defaults to heap size

  • Unless the initial heap size and maximum heap size are specified on the command line, they are calculated based on the amount of memory on the computer. The default maximum heap size is 1/4 of physical memory, and the initial heap size is 1/64 of physical memory.

  • By default, the maximum space allocated to young generations is 1/3 of the total heap size.

Specifications for the parallel collector’s initial and maximum heap sizes

  • You can specify the initial heap size and maximum heap size using the option and -xmx.

    • If you know how much heap your application needs to work properly, you can set -xms and -xmx to the same value.

    • If you don’t know, the JVM will start using the initial heap size and then increase the Java heap until it finds a balance between heap usage and performance.

To verify the defaults, use the -xx :+PrintFlagsFinal option and look for -xx :MaxHeapSize in the output.

For example, on Linux you can run the following command:

java -XX:+PrintFlagsFinal <GC options> -version | grep MaxHeapSize
Copy the code
Excessively long parallel collector time and OutOfMemoryError

If too much time is spent on garbage collection (GC), the parallel collector throws OutOfMemoryError.

OutOfMemoryError is thrown if more than 98% of the total time is spent garbage collection and less than 2% of the heap is recovered. This feature is designed to prevent applications from running for a long time while making little or no progress because the heap is too small. You can add options to the command line if necessary-XX:-UseGCOverheadLimitTo disable this feature.

G1 garbage Collector

  • The goal of the G1 garbage collector is to scale multiprocessor machines to large amounts of memory.
  • It attempts to meet the garbage collection pause time target with high probability while achieving high throughput without configuration.
  • The goal of G1 is to provide the best balance between latency and throughput using the current target application and environment.

While the G1 collector typically has much shorter garbage collection pause times than the throughput collector, application throughput also tends to be slightly lower.

G1 is the default collector.

To enable the G1

The G1 garbage collector is the default collector, so you usually don’t need to do anything else, which you can provide on the command line-XX:+UseG1GCTo explicitly enable it.

The basic concept

G1 is a generational, incremental, parallel, mostly concurrent, stop-the-world and evacuation garbage collector that monitors the time target for each stop-the-world pause.

  • Like other collectors, G1 divides the heap into (virtual) young generations and old generations.
  • Space recovery efforts focus on the younger generation, which is most efficient, and occasionally space recovery in the older generation.
G1 design principles

  • The G1 was designed to “collect as much Garbage as possible First.” Therefore, G1 does not wait until memory runs out (serial, parallel) or is running out of memory (CMS) to start garbage collection. Instead, IT uses heuristic algorithms internally to find partitions with high collection benefits in the old years.

  • G1 uses the Region concept to divide memory into memory partitions of equal size. When reclaiming memory, the system reclaims the memory by Region. Surviving objects are copied to another free partition. Since they all operate in units of equal size, G1 is a natural compression scheme (local compression);

At the same time, G1 can automatically adjust the size of the young generation and the total heap according to the pause time target set by the user. The shorter the pause target, the smaller the space of the young generation and the larger the total space.

  • G1 is also a generational collector, but there is no physical distinction between young and old generations for the entire memory partition, nor does it require a completely separate survivor(to space) heap to prepare for replication. G1 has only logical generational concepts, or the possibility that each partition can switch back and forth between generations as G1 runs;

  • The collection of G1 is all STW, but the collection boundary between the young generation and the old generation is blurred, and a mixed collection method is adopted. That is, each collection can either collect only young generation partitions (young generation collection) or include part of old generation partitions (mixed collection) along with the young generation, so that even when heap memory is large, the collection scope can be limited and pauses can be reduced.

Other operations that the application stops take more time, such as whole heap operations such as global tags that are executed in parallel with the application. In order to shorten the pause time of stop-the-world in space reclamation, G1 performs space reclamation step by step in parallel.

G1 enables predictability by tracking information about previous application behavior and garbage collection pauses to model associated costs. It uses this information to calculate how much work is done at the pause. For example, G1 first reclaims space in the most efficient areas (most of which are garbage, hence the name G1).

G1 reclaims space primarily through evacuation: live objects found in a selected memory region are copied to a new memory region and compressed during processing. After the evacuation is complete, the space previously occupied by the live objects is reused by the application for allocation.

The G1 collector is not a real-time collector. It attempts to achieve the set pause time goal with high probability over a longer period of time, but is not always absolutely certain within a given pause time.

Heap layout

G1 divides the heap into a set of equal-sized heap regions, each with a contiguous virtual memory range. Region regions are units of memory allocation and memory reclamation.

  • At any given time, each of these areas can be empty (light gray) or assigned to a particular generation, young or old.

  • When a memory request comes in, the memory manager allocates free areas. The memory manager allocates them to a generation and then returns them as free space to the application, which can allocate them to itself.

The young generation contains the Eden area (red) and the Survivor area (red with an “S”). These regions provide the same functionality as the corresponding continuous Spaces in other collectors, except that in G1, these regions are usually laid out in memory in a discontinuous pattern. The old areas (light blue) make up the old years. For objects that span more than one region, the old age region can be very large (light blue with an “H”).

Applications are always assigned to the younger generation, the Eden region, except for large objects directly assigned to the older generation.

Garbage collection cycle

At a high level, the G1 collector alternates between the two phases. Only the young-only phase contains garbage collections that gradually fill the currently available memory with objects from the older generation. In the space recovery phase, G1 gradually reclaims the space of the old age in addition to dealing with the problems of the young generation. Then the cycle starts all over again, only in the young stages.

The following list details the phases of the G1 garbage collection cycle, pauses, and transitions between them:

Young-only phase This phase starts with the collection of several Normal Young generations and upgrades objects to older generations. When the old generation occupancy reaches a certain threshold, that is, the initial heap occupancy threshold, the young-only phase and the space-reclamation phase begin to change. At this point, G1 plans a Concurrent Start of a young collection instead of a Normal young collection. Concurrent Start: This type of collection starts the marking process in addition to performing the normal young generation collection. Remark (Remark) : This pause will determine the mark itself, perform global reference processing and class unload, reclaim completely empty areas, and clean up internal data structures. Cleanup: This pause determines whether the space is actually reclaimed. Space-reclamation stage: This stage includes multiple Mixed reclamation, in addition to the young generation area, but also deletes the whole set of active objects in the old generation area. The space reclamation phase ends when G1 decides that deleting more old regions will not create enough free space.

After space is reclaimed, the collection cycle restarts from another young-only phase. As a backup, if the application runs out of memory while collecting survivability information, G1 performs stop-the-world Full heap compression (Full GC) in place, as other collectors do.

G1 Interior Details

Java heap size adjustment

G1 follows standard rules when it comes to resizing the Java heap, Use -xx :InitialHeapSize as the minimum Java heap size, -xx :MaxHeapSize as the maximum Java heap size, and -xx :MinHeapFreeRatio as the minimum percentage of free memory. -xx :MaxHeapFreeRatio Determines the maximum percentage of free memory after resizations. The G1 collector only considers resizing the Java heap during remarking and Full GC pauses. This procedure can free or allocate memory from the operating system.

Young-only Phase generation adjustment

G1 always measures the size of the young generation at the end of the normal young generation collection in the next mutant phase. In this way, the G1 can satisfy the use – XX: MaxGCPauseTimeMillis and – XX: PauseTimeIntervalMillis set pause time target, the target based on the long-term observation of actual pause time. It takes into account how long it would take younger generations of the same size to delete. This includes information such as how many objects need to be copied during the recycling process and how interconnected they are.

  • If there are no other restrictions, G1 can adaptively resize the young generation between the values determined by -xx :G1NewSizePercent and -xx :G1MaxNewSizePercent to meet the pause time requirements.

  • Alternatively, you can use -xx :NewSize and -xx :MaxNewSize to set the minimum and maximum values for the young generation, respectively.

  • Note: Specifying only one of these latter options fixes the young generation size exactly to the value passed with -xx :NewSize and -xx :MaxNewSize, respectively. This will disable pause time control.

Adjustment of space recovery stage

In the space collection phase, G1 tries to maximize the amount of space recovered in the old decade during a garbage collection pause. The youth size is set to the minimum allowed, usually by-XX:G1NewSizePercentSure.

Periodic garbage collection

  • If there is no garbage collection for an extended period of time due to an inactive application, the virtual machine may retain a large amount of unused memory for a long time that could be used elsewhere.

  • To avoid this, force G1 to perform regular garbage collection using the -xx :G1PeriodicGCInterval option. This option determines the minimum interval (milliseconds) at which G1 considers performing garbage collection.

  • If the time has elapsed since any previous garbage collection pauses and there are no concurrent cycles in progress, G1 triggers additional garbage collection.

Determine the initial heap occupancy

Initiating Heap Occupancy Percent (IHOP) is the threshold that triggers initial tag reclamation and is defined as a percentage of old age size.

By default, G1 automatically determines the best IHOP by looking at how long tagging takes during the tagging cycle and how much memory was typically allocated in older generations. This feature is called adaptive IHOP.

If this feature is active, then options – XX: InitiatingHeapOccupancyPercent percentage to determine the size of the initial value as the older generations, as long as not enough observations to predict well start heap usage thresholds.

Disable this behavior in G1 with the -xx: -g1useadaptiveihop option. In this case, the – XX: InitiatingHeapOccupancyPercent always decide the threshold value.

tag

G1 markup uses an algorithm called snapshot-at-the-beginning (SATB). It takes a virtual snapshot of the heap when the initial tag is paused, at which point all objects that were active at the start of the tag are considered active for the rest of the tag. This means that, for space reclamation purposes (with some exceptions), objects that become dead during marking are still considered alive. This may result in some extra memory being incorrectly reserved compared to other collectors. However, SATB may provide better delay during Remark suspension. It is too conservative to consider that live objects will be reclaimed during this marking period.

  • -xx :MaxGCPauseMillis=200 Maximum pause time target
  • -xx :GCPauseTimeInterval= Target of the maximum pause interval. By default, G1 does not set any targets, allowing G1 to perform garbage collection back-to-back in extreme cases.
  • -xx :ParallelGCThreads= Maximum number of threads used for parallel work during garbage collection pauses. This is based on the number of threads available to the machine on which the virtual machine is running: if the process has 8 or fewer CPU threads available, that thread is used. Otherwise, use 5/8 of the number of threads.
  • -XX:ConcGCThreads=
  • -XX:+G1UseAdaptiveIHOP -XX:InitiatingHeapOccupancyPercent=45
  • -XX:G1HeapRegionSize=
  • -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60
  • -XX:G1HeapWastePercent=5
  • -XX:G1MixedGCCountTarget=8
  • -XX:G1MixedGCLiveThresholdPercent=85
Comparison with other collectors

####### Here is a summary of the main differences between G1 and the other collectors:

  • The parallel GC can only compress and reclaim space in the old age as a whole.
  • G1 incrementally distributes this work across multiple shorter collections. This greatly reduces pause times, but reduces throughput.
  • G1 concurrently performs partial old space reclamation.
  • G1 may show higher overhead than the above collector, affecting throughput due to concurrency.
  • ZGC is targeted at very large heaps and is intended to provide smaller pause times at a higher throughput cost.
  • Because of how it works, G1 has some unique mechanisms to improve garbage collection efficiency:

In any recycling process, G1 can reclaim large, completely empty areas of old age. This avoids a lot of other unnecessary garbage collection and frees up a lot of space without much effort G1 can optionally try to deduplicate duplicate strings on the Java heap at the same time. Recycling empty large objects from older generations is always enabled.

You can use – XX: – G1EagerReclaimHumongousObjects option to disable this feature. By default, string deduplication is disabled. You can use options – XX: + G1EnableStringDeduplication enable it.

Z garbage collector

The Z garbage Collector (ZGC) is a scalable low-latency garbage collector. ZGC performs all expensive work concurrently without stopping the execution of application threads for more than 10ms, making it suitable for applications that require low latency or use very large heaps (terabytes).

The garbage collector Z is an experimental features, can from the command line options – XX: + UnlockExperimentalVMOptions – XX: + UseZGC enabled.

Set heap size

The most important tuning option for THE ZGC is to set the maximum heap size (-xmx).

Set the number of concurrent GC threads

The second tuning option that you might want to consider is setting the number of concurrent GC threads (-xx :ConcGCThreads).

Explicit garbage collection

Another way for applications to interact with garbage collection is to explicitly call full garbage collection using system.gc ().

Class Metadata

Java classes have an internal representation in the Java Hotspot VIRTUAL machine called class metadata.