JVM
JVM (Java Virtual Machine)
Java SE (Standard Edition) selects the most appropriate garbage collector based on the class of the computer on which the application is run. However, this selection may not be optimal for every application. Users may need to explicitly select the garbage collector and tune certain parameters to achieve the desired level of performance.
The JVM provides platform-dependent default selections for the garbage collector, heap size, and runtime compiler. These selections match the needs of different types of applications while requiring less command-line tuning. In addition, behavior-based tuning dynamically optimizes the sizes of the heap to meet a specified behavior of the application.
GC
GC (Garbage Collector)
The GC automatically manages the application's dynamic memory allocation requests.
The purpose of a garbage collector is to free the application developer from manual dynamic memory management. The developer is freed of the requirement to match allocations with deallocations and closely take care of the lifetimes of allocated dynamic memory. This completely eliminates some classes of erros related to memory management at the cost of some additional runtime overhead.
Amdahl's law (parallel speedup in a given problem is limited by the sequential portion of the problem) implies that most workloads can't be perfectly parallelized; some portion is always sequential and doesn't benefit from parallelism. In the Java platform, there are currently four supported garbage collection alternatives and all but one of them, the serial GC, parallelize the work to improve performance. It's very important to keep the overhead of doing garbage collection as low as possible.
Cleaning our applications' JVM process heap memory is not free. There are resources that need to be designated for the garbage collector so it can do its work. You can imagine that instead of handling the business logic of our applicatoin the CPU can be busy handling the removal of unused data from heap.
This is why it's crucial for the garbage collector to work as efficiently as possible. The GC process can be heavy. This can lead to your users not being able to properly use your application at all. Your distributed systems can collapse because of elements not responding in a timely manner.
The serial collector is usually adequate for most small applications, in particular those requiring heaps of up to approximately 100 megabytes on modern processors. The other collectors have additional overhead or complexity, which is the price for specialized behavior. If the applcation does not need the specialized behavior of an alternate collector, use the serial collector. One situation where the serial collector isn't expected to be the best choice is a large, heavily threaded application that runs on a machine with a large amount of memory and two or more processors. When applications are run on such server-class machines, the G1 collector is selected by default.
Dynamic memory allocation management by GC
1. Allocates from and gives back memory to the OS.
2. Hands out that memory to the application as it requests it.
3. Determines which parts of that memory is still in use by the application.
4. Reclaims the unused memory for reuse by the application.
GC Strategies
- Use generational scavenging
A reclamation algorithm that has no noticeable pausesin conjunction with aging to concentrate their efforts on areas in the heap that most likely contain a lot of reclaimable memory areas. - Use multiple threads to aggressively make operations parallel, or perform some long-running operations in the background concurrent to the application.
- Try to recover larger contigious free memory compacting live objects.
Garbage collector, Heap, and Runtime Compiler Default Selections
- Garbage-First(G1) Collector
- The maximum number of GC threads is limited by heap size and available CPU resources
- Initial heap size of 1/64 of physical memory
- Maximum heap size of 1/4 of physical memory
- Tiered compiler, using both C1 and C2
Behavior-based Tuning
The Java Hotspot VM garbage collectors can be configured to preferentially meet one of two goals: maximum pause-time and application throughput단위 시간 당 디지털 데이터 전송으로 처리하는 양(bps). If the preferred goal is met, the collectors will try to maximize the other. Naturally, these goals can't always be met: Applications require a minimum heap to hold at least all of the live data, and other configuration might preclude reaching some or all of the desired goals.
Maximum Pause-Time Goal
The pause time is the duration during which the garbage collection stops the application and recovers space that's no longer in use. The intent of the maximum pause-time goal is to limit the longest of these pauses.
An average time for pauses and a variance on that average is maintained by the garbage collector. The average is taken from the start of the execution, but it's weighted so that more recent pauses count more heavily. If the average plus the variance of the pause-time is greater than the maximum pause-time goal, then the garbage collector considers that the goal isn't being met.
The maximum pause-time goal is specified with the command-line option -XX:MaxGCPauseMillis=<nnn>. This is interpreted as a hint to the garbage collector that a pause-time of <nnn> milliseconds or fewer is desired. The garbage collector adjusts the Java heap size and other parameters related to garbage collection in an attempt to keep garbage collection pauses shorter than <nnn> milliseconds. The default for the maximum pause-time goal varies by collector. These adjustments may cause garbage collection to occur more frequently, reduing the overall throughput of the applicatoin. In some cases, though, the desired pause-time goal can't be met.
Throughput Goal
The thorughput goal is measured in terms of the time spent collecting garbage, and the time spent outside of garbage collection is theapplication time.
The goal is specified by the command-line option --XX:GCTimeRatio=nnn. The ratio of garbage collection time to application time is 1/ (1+nnn). For example, -XX:GCTimeRatio=19 sets a goal of 1/20th or 5% of the total time for garbage collection.
The time spent in garbage collection is the total time for all garbage collection induced pauses. If the throughput goal isn't being met, then one possible action for the garbage collector is to increase the size of the heap so that the time spent in the application between collection pauses can be longer.
Footprint
If the throughput and maximum pause-time goals have benn met, then the garbage collector reduces the size of the heap until one of the goals (invariably the throughput goal) can't be met. The minimum and maximum heap sizes that the garbage collector can use can be set using -Xms=<nnn> and -Xmx=<mmm> for mimimum and maximum heap size respectively.
Ref)
https://docs.oracle.com/en/java/javase/13/gctuning/index.html#Java-Platform%2C-Standard-Edition
https://sematext.com/blog/java-garbage-collection/
https://sematext.com/blog/java-garbage-collection-tuning/
