Supporting Multiple Garbage Collectors in a Single GraalVM Native Executable

GraalVM Native Image is a tool for ahead-of-time (AOT) compilation of Java byte code
to optimized native executables. A native executable includes all necessary components for execution including the virtual machine (VM) and the garbage collector (GC). Native Image supports three different GCs, but only one GC can be included in an executable. For using a different GC, a different executable has to be built. This thesis implements the support for including multiple GCs in a single native executable. The used GC can then be selected at run-time. Additionally, it describes two optimizations to improve the performance and reduce the memory footprint of the Serial GC. The first optimization tries to reduce the unused memory in thread-local allocation buffers (TLABs) by sizing them dynamically based on the allocation behavior of the thread. The other optimization tries to improve the performance by using precise write barriers for large arrays. This reduces the number of references the GC has to visit for large object arrays.
Finally, this thesis evaluates the performance of the implementations with benchmarks. Native executables that include both the Garbage-First (G1) and the Serial GC do not show any performance change when G1 is selected at run-time compared to a native executable including only G1. When the Serial GC is selected, the performance depends on the application as some benchmarks show performance improvements and some performance regressions compared to executables including only the Serial GC. Overall, it has a performance regression of 3 %. On average, the Serial GC with dynamically sized TLABs shows a 9 % improvement of the maximum resident set size (RSS) and a 3 % performance reduction compared to using fixed sized TLABs. The performance of the precise write barriers depends on the application. Benchmarks that use large arrays show performance improvements of up to 15 % when using precise write barriers compared to using imprecise write barriers. Benchmarks that do not use large arrays, do not show any changes of their performance or binary size.