Why is AtomicFU mapping something like `atomic(1)`...

# multiplatform

[Edoardo Luppi]

Why is AtomicFU mapping something like atomic(1) to an AtomicIntegerFieldUpdater instead of using an AtomicInteger?
What's the reasoning behind it?

[ephemient]

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html

In addition to classes representing single values, this package contains Updater classes that can be used to obtain compareAndSet operations on any selected volatile field of any selected class. AtomicReferenceFieldUpdater, AtomicIntegerFieldUpdater, and AtomicLongFieldUpdater are reflection-based utilities that provide access to the associated field types. These are mainly of use in atomic data structures in which several volatile fields of the same node (for example, the links of a tree node) are independently subject to atomic updates. These classes enable greater flexibility in how and when to use atomic updates, at the expense of more awkward reflection-based setup, less convenient usage, and weaker guarantees.

[Edoardo Luppi]

So, basically, since nowadays AtomicFU works with compile-time transformations, they've chosen the "awkward" way on their side to obtain possible improvements at runtime?

[ephemient]

afaik it's not any more awkward for atomicfu

[jw]

Hasn't atomicfu always been compile-time based? Otherwise you'd just expect/actual a heap-allocated wrapper like everyone else

[Edoardo Luppi]

You're probably right. I think what has changed is they're now using IR

[ephemient]

it changed from a postprocessor of the compiled output to a compiler plugin

[jw]

Yeah it used to do very questionable things using JS, bytecode, and native always used Kotlin IR, I think