Quarkus, the Kubernetes Native Java Framework, has switched its default garbage collection (GC) policy from space/time to adaptive GC for native runtime in version 2.13.6.Final. Adaptive GC is designed to aggressively trigger GCs in order to keep memory consumption low. This makes it more effective in situations where a low memory footprint is important, and it appears to perform better under heavy stress.
This is in response to concerns about the impact of the space/time policy on memory consumption and performance in some situations. While space/time is generally effective in balancing young and full GCs and is currently the default for Quarkus, it can cause odd memory consumption when physical memory is over three gigabytes, and no maximum heap size (-Xmx) is configured.
Adaptive GC is GraalVM CE's default GC policy for serial GC. It is based on HotSpot's ParallelGC adaptive size policy but with a greater focus on memory footprint. This means that, unlike space/time, it aggressively triggers GCs to keep memory consumption down. Adaptive GC tracks the pause time in consecutive minor collections and schedules a full GC if a threshold is passed, making it more effective at mitigating potential GC nepotism issues.
However, Quarkus may still choose to retain space/time as an option. The lack of survivor spaces in space/time means that young-lived objects can easily build up in the old generation until full GC, leading to potential spikes in memory consumption. Furthermore, some developers may still prefer the predictability of space/time in certain situations.
There are potential risks associated with both policies. The space/time policy requires the passing of a non-public API (-H:) to set up, which may not be sustainable in the long term. On the other hand, switching to adaptive GC could generate fewer full GC events, which is one of space/time's main features. The serial GCs old generation could also switch from copying to mark-sweep-compact, which would require further evaluation of the cost of full GCs.
Quarkus' potential switch to the adaptive GC policy underscores the importance of selecting the right GC policy for the situation. Developers must consider factors such as physical memory, workload stress levels, and the need for a low memory footprint. A deep understanding of GC policies can help developers optimize application performance and minimize memory consumption.
Developers who are interested in learning more about the investigation into native memory usage in Quarkus can refer to the original GitHub issue for further details. Quarkus has also made it easier for developers to optimize how their apps use memory by adding a new section to their Reference Guide called "Native Memory Management." By taking advantage of these resources, developers can gain a deeper understanding of how their applications use memory and make more informed decisions to improve performance.