JDK 17: Using ParallelGC for the Kotlin process in Android Builds

In the previous article, we explained the results of using ParallelGC in the Kotlin process for the project nowinandroid. The results showed:

• 22% Kotlin Compile aggregated task time improvement
• 60% garbage collector time improvement of the Kotlin process
• 51% usage reduction of the Kotlin process memory usage

The article measured the project using AGP 7.4.1 and JDK 11. Since AGP 8.0.0, the min version required is JDK 17 and we have pending to repeat the experiment on different types of GCs in the current tooling. This article shows the results found when using AGP 8.0.0 and JDK 17 with the different types of garbage collectors.

Experiment

Environment

• Linux 5.15.0-1035-azure (amd64)
• 2 CPU cores
• 2 Gradle workers
• 3 Gb memory heap size
• Github Action agent

Project

• nowinandroid (commit c746b6afcdeef23ae00ae4ec0d1d403ef28e62e2 - 04/27)
• JDK 17
• Gradle 8.1
• AGP 8.0.0
• KGP 1.8.10
• Hilt 2.44.2

Experiment Variants

Methodology

• Each variant runs 40 Gradle profiler scenarios
• Each scenario runs one warm-up and five builds
• Each scenario applies a Gradle profiler scenario with an abi change on the module core:datastore(Highest betweenness centrality in the project dependency graph). The task executed for each scenario is clean :app:assembleDebug
• This type of scenario generates for each execution:
  • 540 tasks executed
  • 26 Kotlin Compiler tasks executed in 12 projects
  • 28 Java Compiler tasks executed in 12 projects
  • We have ignored the warm-up and first build in all the results of each execution

Results

Builds

Data extracted from the outputs generated for each Gradle Profiler execution, duration in milliseconds

Mean by variant

Kotlin Compiler

Aggregated build time of the Kotlin Compiler tasks with the outcome "SUCCESS" using Gradle Enterprise API, duration in milliseconds:

Mean by variant

Kotlin process

Retrieving the Kotlin process information using InfoKotlinProcess:
GC Time
Garbage Collector time in minutes:

Mean by variant

Usage
Kotlin process usage in GB:

Mean by variant

ZGC

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector. ZGC was initially introduced as an experimental feature in JDK 11, and was declared Production Ready in JDK 15. Because Android projects target JDK 17, we could use this type of collector in our experiments.

Our first attempt to add two additional variants failed, the variant using ZGC for the Gradle and Kotlin processes showed a significant memory pressure on the Gradle Daemon, this situation affects the measurements on the Kotlin process, Gradle process performance:

Kotlin process:

With that, I don't want to say that ZGC is not suitable for Android builds. In this case, I think the short memory configuration for the Android environment in Github Action(3Gb for the Gradle process) is causing the slower build times for both processes.

However, we could ignore the variant gz_kz and focus on the results of using ZGC for the Kotlin process and Parallel for Gradle process(gp_kz).

Experiment Variants

Results

These results have ignored the slowest variants in the experiments for the Kotlin process (gp_kg and gg_kg).

Build time

Mean by variant

Kotlin Compiler

Mean by variant

Final words

The combination of ParallelGC for both processes is again giving the best result for Build times and Kotlin compiler task durations.
The new ZGC for the Kotlin process is promising, given the constrained environment where the experiments were executed.
As we mentioned in the previous article, you need to measure what matters in your project, CI pipelines could contain expensive builds with R8 tasks or endless test tasks, and we just covered assembleDebug.

Happy Building