Tip #1: Don’t Obsess Over Garbage

I find that sometimes Java developers obsess over the amount of garbage their applications produce. Very few cases warrant this sort of obsession. A garbage collector (GC) helps the Java Virtual Machine (JVM) in memory management. For OpenJDK HotSpot VM, the GC along with the dynamic just-in-time (JIT) tiered compiler (client (C1) + server class (C2)) and the interpreter make up its execution engine. There are a slew of optimizations that a dynamic compiler can perform on your behalf. For example, C2 can utilize dynamic branch prediction and have a probability (“always” or “never”) for code branches taken (or not). Similarly, C2 excels in optimizations related to constants, loops, copies, deoptimizations, and so on.

Trust the adaptive compiler, but when in doubt verify using “serviceability,” “observability,” logging, and all the other such tools that we have thanks to our rich ecosystem.

What matters to a GC is an object’s liveness/age, its “popularity,” the “live set size” for your application, the long-lived transients, allocation rate, marking overhead, your promotion rate (for the generational collector), and so forth.

Tip #2: Characterize and Validate Your Benchmarks

A peer of mine once brought in some observations of a benchmarking suite with various sub-benchmarks. One of these was characterized as a “start-up and related” benchmark. After taking a look at the performance numbers and the premise that was the comparison between OpenJDK 8u and OpenJDK 11u LTS releases, I realized that the difference in numbers could have been due to the default GC changing from Parallel GC to G1 GC. So, it seems that the (sub-)benchmark either was not properly characterized or wasn’t validated. Both are important benchmarking exercises and help identify and isolate the “unit of test” (UoT) from other components of the test system that could act as detractors.

Tip #3: Allocation Size and Rate Still Matter

In order to be able to get to the bottom of the issue discussed above, I asked to see the GC logs. Within minutes, it was clear that the (fixed) region size, which is based on the heap size of the application, was categorizing the “regular” objects as “humongous.” For the G1 GC, humongous objects are objects that span 50% or more of a G1 region. Such objects don’t follow the fast path for allocations and are allocated out of the old generation. Hence, allocation size matters for regionalized GCs.

A GC keeps up with the live object graph mutation and moves objects from the “From” space into the “To” space. If your application is allocating at a rate faster than your GC’s (concurrent) marking algorithm can keep up with, then that can become a problem. Also, a generational GC may prematurely promote short-lived objects or not age transients properly due to the influx of allocations. OpenJDK’s G1 GC is still working on not being dependent on its fallback, fail-safe, nonincremental, full heap traversing, (parallel) stop-the-world collector.

Tip #4: An Adaptive JVM Is Your Right and You Should Demand It

It’s great to see an adaptive JIT and all the advancements geared toward start-up, ramp-up, JIT availability, and footprint optimizations. Similarly, various GC-level algorithmic smartness is available. Those GCs that aren’t there yet should get there soon, but that won’t happen without our help. As Java developers, please provide feedback on your use case to the community and help drive innovation in this area. Also, do test out the features that are continually getting added to the JIT.