Understanding certain fundamental words relating to the type of trash collector is crucial before talking about it.
- Stop the World Event: This occurs when all application threads are suspended pending the conclusion of the trash collection process. Garbage pickups, both small and large, are “Stop the World” occasions.
- -Xms: The initial heap size for JVM is specified by this command-line option. When the JVM starts, it establishes the initial heap size.
- Xmx: Maximum heap size is determined by the -Xmx option.
- Xmn: The Young Generation’s size is determined by the -Xmn.
- XX:PermSize: The Permanent Generation’s initial size is set by the -XX: PermSize option.
- -XX: MaxPermSize: Defines the Permanent Generation’s largest possible size.
Garbage Collector Types:
1. Sequential GC:
Serial GC is intended for situations with only one thread. For garbage collection, it just uses one thread. Because of this, whenever this GC implementation executes, all application threads are frozen. This causes the global event to end. Therefore, using it in multi-threaded applications like server environments is not a good idea. JVM’s justification for employing a serial garbage collector is:
| -XX:+UseSerialGC |
Use: When you don’t need a short pause time and your GC operates on client-style machines, serial GC is a good choice.
Figure 01: Serial GC
2. Concurrent GC
Throughput Collectors is another name for this. because it can increase application throughput by using many CPUs. When a lot of work needs to be done and lengthy breaks are permissible, this collector should be utilized. For instance, batch processing can involve printing invoices or reports or doing a lot of database queries. It was created specifically for multi-threaded settings. It employs several simultaneous trash collection threads. Additionally, when this GC implementation is in use, all application threads are frozen, which results in a “stop the world event.” JVM’s justification for employing a parallel garbage collector is:
| -XX:+UseParallelGC |
The following options can be used to determine the maximum number of garbage collection threads, pause duration, and throughput in parallel GC.
- To limit the number of threads used by the trash collector
| -XX:ParallelGCThreads=<n> |
Where n = the number of GC threads
- To define the longest possible pause period (the interval between two GCs)
| -XX:MaxGCPauseMillis=<n> |
where n = the amount of time in milliseconds
- To define the maximum throughput target (measured in terms of the time spent performing garbage collection compared to the time spent otherwise).
| -XX:GCTimeRatio=<n> |
where n compares GC time to non-GC time
Use: Where a lot of work needs to be done and lengthy pauses are allowed, parallel GC is useful
Figure 02: Parallel GC
3. Concurrent Mark Sweep (CMS) General Control:
The tenured generation is gathered by Concurrent Mark Sweep (CMS), a garbage collector. Alternatively, it is known as the concurrent low pause collector. By performing the majority of the trash collection work concurrently with the application threads, it tries to reduce the pauses caused by garbage collection. The CMS collector uses more CPUs than other GCs for this reason. The CMS garbage collector is favored over the parallel collection if you have additional CPU resources available for improved performance. Multiple threads are used by the CMS garbage collector to scan the heap memory, flag instances for eviction, and then sweep the flagged instances. Only when does the world event stop happening.
- Labeling the relevant items in the space for tenured generation.
- If there is a parallel modification to the heap memory while the garbage collection is being done.
JVM’s justification for using the CMS garbage collector is:
| -XX:+UseConcMarkSweepGC |
Setting the thread count involves:
| -XX:ParallelCMSThreads=<n> |
Where n = the number of GC threads
Uses: When a low pause time is required and resources (memory, CPU) may be shared with the garbage collector, CMS GC is beneficial.
Figure 03: CMS Garbage Collector
4. G1 GC:
The G1 (Garbage First) Garbage Collector is made for programs that use multi-processor computers with a lot of memory (more than 4GB). Depending on how big the heap is, the G1 collector divides it up into a number of equal-sized heap regions (1MB to 32MB). This equal-sized sector is used for the memory allocation of the objects in the Eden, survivors, and old area.
There are three other sorts of memory regions in the G1 GC method in addition to Eden, Survivor, and Old (Tenured) memory regions.
- Humongous
- Available
The Available section displays unused space, whereas the Humongous sector is used for huge objects. G1 displays a concurrent global marking phase to identify the active and dead objects throughout the heap while doing garbage collections. G1 knows which regions contain the most garbage items when the mark phase is finished, thus those regions are swept first. Because of this, the garbage-first collection approach is so named. JVM’s justification for employing the G1 garbage collector is:
| -XX:+UseG1GC |
Several crucial G1GC Related points include:
• Consecutive memory spaces in G1 are divided into designated regions with specific sizes.
• The 2048 (2K) fields are the base target value for the region. An area is 4MB in size if the Java heap can be as large as 8G. (8192MB / 2048 = 4MB)
• The -XX: G1RegionSize option can change the region space from 1 MB to 32 MB, but direct tuning is not recommended.
• Large regions do not benefit from optimized GC performance. Therefore, it is a good idea to evaluate the software to determine why large objects are a problem if using G1 GC results in large object problems.
• Some improvements have been made to the G1 garbage collector in Java 8.
The G1 garbage collector is used in conjunction with the JVM parameter XX:+UseStringDeduplication. This helps reduce the number of duplicate string values in a single char[] array.
Some other justifications:
| -XX:InitialHeap Occupancy Percentage=<n> |
- to control how much heap space is occupied when a concurrent loop begins. 45% is the standard percentage:
where n = % heap space.
- This option is not included in the GC object if there is a live object in the OLD region with a value greater than or equal to it. 65 is the default setting. –
| XX: G1MixedGCLiveThresholdPercent= |
n = the amount of time in milliseconds
- to define the maximum number of wasted areas. 10 is the default.
| -XX:G1HeapWastePercent=<n> |
Where n = the number of regions
Use: The G1 GC is advantageous when multiple processors and lots of memory are available. On a memory-heavy machine, G1 GC outperforms others in terms of GC.
Figure 04: G1 GC
