The future of kotlinx-atomicfu. Multiplatform Atomic types in the Kotlin Standard library.

[mvicsokolova]

The primary purpose of the kotlinx-atomicfu library has been to provide multiplatform atomic types for Kotlin, along with optimizations achieved through inlining. To enable this, the library introduced it’s own atomic types, such as:

• kotlinx.atomicfu.Atomic(Int|Long|Boolean|Ref)
• kotlinx.atomicfu.Atomic(IntArray|LongArray|Array)

Initially, optimization was handled by the library's transformers, which performed bytecode transformations for JVM and *.js file transformations for JavaScript. Later, the atomicfu-compiler-plugin supported this optimization for JVM and Native by transforming IR.

With the upcoming Common Atomic Types in the Kotlin standard library 🎉 (which will be available from Kotlin 2.1.20-Beta1 as Experimental API, KT-62423, KEEP), the future of the kotlinx-atomicfu library must be planned.

The standard library will introduce atomic types in kotlin.concurrent package, including:

• AtomicInt, AtomicLong, AtomicBoolean, and AtomicRef<T>
• AtomicIntArray, AtomicLongArray, and AtomicArray<T>

This new Atomic API will eliminate the need for kotlinx.atomicfu custom atomic types. Furthermore, optimization of these standard atomic types will transition to the new light atomicfu compiler plugin.

Light atomicfu compiler plugin

This new compiler plugin will replicate the core functionality of the current atomicfu-compiler-plugin, specifically inlining kotlin.concurrent Atomic types at the IR level for JVM and Native. Users will have control over which atomics to inline by applying a dedicated annotation, such as @InlineAtomic.

import kotlin.concurrent.*

@InlineAtomic
private val counter = AtomicInt(0)

I call the plugin “light” in the sense, that some features, which were previously provided by the library, will be omitted, such as:

• debug tracing (kotlinx.atomicfu.Trace)
• property delegation to atomics
• extension functions on atomic types (to be discussed)

The specific scope of supported features will be discussed later to maximize reliability, as the plugin will become part of the language. The YT issue to track the status: KT-73731

Once the light atomicfu compiler plugin is introduced and the migration process is complete, the kotlinx-atomicfu library will no longer be necessary and will be archived.

Transition timeline

For now, kotlin.concurrent atomics are on the way and will be accessible starting from Kotlin 2.1.20-Beta1, but the light compiler plugin is not yet planned to be introduced by 2.1.20. So no deprecation of the kotlinx-atomicfu API is planned till the light atomicfu compiler plugin is introduced, which will be announced. Here is the timeline:

1. Currently, we are migrating to the existing atomicfu compiler plugin: enabling compiler plugin transformations by default, deprecating JVM legacy bytecode transformation (Deprecate JVM bytecode transformer #338), JS transformation(Turn off by default / remove JS IR transformations #431), removing debug tracing support.
2. As soon as the light atomicfu compiler plugin supports optimization of the kotlin.concurrent atomics and is released, the migration to this plugin will start: kotlinx.atomicfu API will be deprecated in favor of kotlin.concurrent Atomics, the exisiting atomicfu compiler plugin will be deprecated as well in favor of the light atomicfu compiler plugin. Ideally, IDE support will be introduced as well.
3. After the migration process is completed, the library will be archived.

---

Taking this plan into consideration, some issues in the kotlinx-atomicfu library with feature suggestions or some other issues will be closed referencing this ticket.