https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
e

Edoardo Luppi

03/30/2024, 6:14 PM
Why is AtomicFU mapping something like
atomic(1)
to an
AtomicIntegerFieldUpdater
instead of using an
AtomicInteger
? What's the reasoning behind it?
e

ephemient

03/30/2024, 6:19 PM
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.
e

Edoardo Luppi

03/30/2024, 6:21 PM
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?
e

ephemient

03/30/2024, 6:23 PM
afaik it's not any more awkward for atomicfu
j

jw

03/30/2024, 7:52 PM
Hasn't atomicfu always been compile-time based? Otherwise you'd just expect/actual a heap-allocated wrapper like everyone else
e

Edoardo Luppi

03/30/2024, 7:53 PM
You're probably right. I think what has changed is they're now using IR
e

ephemient

03/30/2024, 7:53 PM
it changed from a postprocessor of the compiled output to a compiler plugin
gratitude thank you 1
j

jw

03/30/2024, 7:53 PM
Yeah it used to do very questionable things using JS, bytecode, and native always used Kotlin IR, I think