Android Developers Get Up to 2x Faster Kotlin Coroutines with R8 Optimizations in AGP 9.2.0

By Andrei Shikov, Senior Software Engineer, Android Toolkit and Jonathan Starup, Software Engineer, R8 Team

Android developers utilizing Kotlin coroutines are set to experience a significant performance boost starting from Android Gradle Plugin (AGP) version 9.2.0. A new optimization implemented within the R8 compiler automatically transforms most Atomic*FieldUpdater calls into direct Unsafe variants. This architectural adjustment delivers a performance increase ranging from two to four times better on common operations.

The optimization has a particularly profound impact on the kotlinx.atomicfu library, which serves as the underlying mechanism for implementing atomic operations within kotlinx.coroutines. By streamlining these execution pathways, launching and cancelling coroutines can now run up to twice as fast. Developers eager to harness these efficiency gains need only update their project configuration to AGP 9.2.0 or higher.

As the overwhelming majority of modern Android applications embrace Kotlin as their primary programming language, kotlinx.coroutines has firmly established itself as the de facto standard for asynchronous programming. The library provides a robust, well-designed, and structured framework for managing concurrent flows in a manner that feels completely native to the language. When Google introduced Jetpack Compose, the modern declarative UI toolkit followed suit by adopting coroutines for managing pointer events, animations, and a wide array of user interactions. Consequently, the vast majority of concurrent APIs within Compose invoke suspend functions under the hood, continually launching and cancelling coroutines to handle real-time state updates.

However, as the Jetpack Compose engineering team began investigating deep performance metrics, coroutines were unexpectedly discovered to be a performance bottleneck for numerous operations executing outside of actual UI composition. For instance, diagnostic profiling revealed that approximately eighty percent of the total CPU time spent creating and updating Modifier.clickable was consumed entirely by the overhead of launching and cancelling internal coroutines designed to handle InteractionSource updates. Based on these critical empirical observations, much of the early performance optimization work focused intensely on removing coroutines from the default execution path and deferring their initialization until absolutely necessary.

The Cost of a Coroutine

The most straightforward and effective method for analyzing the internal runtime behavior of a function on the Android platform is capturing an Android Runtime method trace. An ART method trace is an invaluable diagnostic tool that meticulously records the complete execution flow of an application. It reveals the exact sequence of method calls, their chronological order, and the precise amount of time spent inside each individual function, thereby enabling software engineers to isolate elusive performance bottlenecks. When visualizing an empty LaunchedEffect block through this lens, the structural execution pattern becomes exceptionally clear.

An examination of a standard method trace reveals that the lifecycle of a coroutine invocation can be broadly separated into distinct phases involving creation, execution, and eventual completion or cancellation. The process of cancelling a LaunchedEffect shares strong similarities with normal completion, with the notable exception that it additionally instantiates a CancellationException to cleanly unwind the coroutine scope.

Within these performance profiles, a suspicious pattern immediately emerges through the frequent, repetitive calls into java.util.concurrent.AtomicReferenceFieldUpdater. While each individual invocation of these updaters appears relatively fast on paper, the sheer frequency of their execution raises alarms. Any non-negligible overhead, when multiplied across thousands of rapid invocations, can rapidly accumulate into a noticeable performance regression. Zooming in closely on an individual call reveals an unexpected culprit: the majority of the execution time is being consumed by internal reflection checks.

Coroutines rely heavily on a sophisticated, lock-free tree structure to maintain parent-child relationships, which is the foundational architecture making structured concurrency possible. Under the hood, the kotlinx.atomicfu library implements these lock-free atomic operations by leveraging a well-known Java Virtual Machine primitive known as AtomicReferenceFieldUpdater. This updater utilizes a class reference and a specific field name to execute atomic memory operations at runtime. To guarantee safety, it must execute several reflective security and existence checks every single time to ensure the target field actually exists and remains accessible. Because every core coroutine operation—including starting, suspending, cancelling, and completing—calls at least one atomic operation, any underlying slowness in this mechanism directly degrades overall coroutine performance.

Investigating AtomicReferenceFieldUpdater

Despite these observations, engineers must exercise caution before drawing final conclusions. The AtomicReferenceFieldUpdater class has actually been heavily optimized on the standard Java Virtual Machine for over a decade. Furthermore, standard method traces can sometimes capture overhead that is subsequently eliminated entirely by virtual machine optimizations, such as Just-In-Time or Ahead-Of-Time compilations. To rigorously verify real-world performance on Android hardware, developers can construct microbenchmarks that directly measure the operational difference between atomic references originating from kotlinx.atomicfu and those from standard Java utilities.

Executing such benchmarks on physical hardware—such as a Google Pixel 5 running API level 33, while ensuring that the underlying field updaters are thoroughly JIT-compiled during a warm-up phase—yields clear, quantitative disparities. The native Java atomic reference implementations consistently outperform the reflective alternatives by a significant margin. These benchmark measurements confirm that the Android Runtime does not perform any hidden runtime magic to bypass the performance penalty. Consequently, the reflective access checks impose genuine, measurable overhead during day-to-day execution.

Looking back at the original method traces, the only genuinely meaningful work performed by the AtomicReferenceFieldUpdater is the internal invocation of Unsafe.getObjectVolatile, which executes the raw, underlying atomic memory instruction. In the vast majority of production codebases, the initialization of these updaters is static and can be statically proven to be entirely correct based on the rigid structure of the enclosing class. Consequently, a sufficiently advanced compiler can analyze most usages of AtomicReferenceFieldUpdater and safely rewrite them into internal Unsafe variants directly during the compilation phase. As it turns out, the Android build toolchain features a powerful, full-program optimizing compiler capable of performing precisely this transformation.

Optimization with R8

While the Atomic*FieldUpdater classes inherently support subtle, dynamic, and reflection-heavy programming patterns, they are overwhelmingly utilized in statically obvious, predictable patterns across modern Android applications. This dichotomy explains both the slow baseline performance observed in profiling and the feasibility of optimization. R8 functions as a comprehensive, full-program optimizing compiler that is exceptionally well-suited to peer through straightforward code patterns and strip away the persistent overhead of reflective safety checks. R8 accepts JVM bytecode generated by either the Java or Kotlin compiler, though developers often visualize these transformations in standard Java syntax for readability.

In a typical scenario, a codebase might instantiate a static final updater to access a volatile field using simple constant arguments specifying the holder class, the expected field type, and the literal name of the target field. Under these conditions, the reflection being utilized is entirely transparent. A static analysis of the source reveals unequivocally that the updater references a valid field and that the initialization site possesses correct access permissions.

At its core, an Atomic*FieldUpdater is simply an abstraction layer acting as a convenient wrapper around a raw memory field offset and direct calls to Unsafe. The ideal scenario for compiler optimization, therefore, is to completely eliminate the cumbersome updater field, replace it with a direct memory offset field, and swap all updater method calls with direct invocations of Unsafe.

The engineering team implemented this sophisticated optimization pipeline across three distinct phases: instrumentation, replacement, and clean-up.

The initial instrumentation phase introduces raw offset fields directly alongside the original updater field within the class definition. This structural addition paves the way for direct memory access via subsequent Unsafe calls. The field offset is extracted at the class level, while the holder type and volatile field type are tracked statically by the compiler. Crucially, the original field and its initialization code are left completely intact during this initial pass, allowing for an optimistic optimization strategy that can gracefully handle partial optimizations where certain usages are modernized while others remain untouched.

Following the instrumentation phase, the compiler evaluates a comprehensive list of tracked updater fields and optimizes individual call sites based on strict eligibility criteria. When an updater method call is encountered, the compiler verifies that the access is static, the holder and field types match precisely, and no dynamic ambiguity exists. If all conditions are successfully met, the high-level method call is replaced entirely with a direct call to Unsafe that completely bypasses all reflective safety checks. Although these generated Unsafe calls are vastly simpler and faster, they handle null values differently than the original wrapper classes. To maintain absolute safety, the compiler automatically injects explicit null-checks for both the holder and updater parameters unless they are statically proven to be non-null.

The final clean-up phase ensures that no redundant code bloat remains in the final application binary. At this stage, the enclosing class may contain the original updater field, the newly introduced offset field, and various call sites utilizing either mechanism. If no call sites were successfully optimized, the compiler discards the offset field. Conversely, if all call sites were optimized, the original updater field is purged from the codebase entirely. While the compiler naturally handles the removal of general dead code and unused fields, cleaning up the initialization logic requires specialized handling. Because methods like newUpdater and getDeclaredField carry potential side effects—such as throwing runtime exceptions whose implementations depend heavily on the underlying API version—generic optimization passes cannot safely remove them automatically. Consequently, the clean-up logic explicitly targets the instrumented fields, as they are statically guaranteed to be exception-free.

Results and Future Outlook

Following the deployment of these robust optimizations, applications leveraging kotlinx.atomicfu alongside explicit uses of integer, long, and reference field updaters now achieve performance levels that match raw AtomicReference benchmarks under R8. In certain scenarios, performance exceeds previous baselines; the kotlinx.atomicfu compiler plugin can inline atomic instances directly into fields, drastically reducing the object allocations normally required to maintain atomically updated properties.

Jetpack Compose has emerged as the primary beneficiary of these engineering improvements. The Compose runtime suite features an extensive suite of microbenchmarks designed to track coroutine performance with high fidelity, ensuring that performance regressions are caught early in the development cycle. When engineers updated their benchmark environments to incorporate the new version of R8, they documented an astounding twofold performance improvement when launching and cancelling coroutines inside LaunchedEffect blocks.

Beyond the contributions of the R8 compiler team, engineers on the Android Runtime team are actively implementing similar optimizations natively at the virtual machine level. For applications targeting API level 37 and running on modern Android hardware, the operating system may already be optimizing coroutine execution paths dynamically. Recent performance evaluations of coroutine benchmarks on newer ART builds have revealed an additional fifteen percent performance increase stemming directly from these JIT enhancements.

Developers can incorporate these vital optimizations into their production applications simply by upgrading their build pipeline to Android Gradle Plugin version 9.2.0 or by integrating R8 version 9.2.0 directly into their existing build configurations.