This commit explicitly sets LV 1.9 for all projects with disabled FIR
bootstrap, as well as for libraries, including Native stdlib.
Related to KT-59171
This is an attempt to bring consistency to array constructors reified requirement.
Currently,
JVM - reified type in all three: arrayOfNulls, arrayOf, emptyArray
Native - reified in arrayOfNulls and arrayOf, but not in emptyArray
JS & Wasm - reified in arrayOfNulls, but not in arrayOf and emptyArray
Merge-request: KT-MR-11005
Merged-by: Abduqodiri Qurbonzoda <abduqodiri.qurbonzoda@jetbrains.com>
These intrinsics are equivalent to KMutableProperty0.get/set invocation and used internally to optimize allocation of a property reference.
Merge-request: KT-MR-11233
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Also enables the integration tests for custom allocator and the
currently available GCs.
Co-authored-by: Troels Bjerre Lund <troels@google.com>
Merge-request: KT-MR-11199
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
This commit introduces API for AtomicIntArray, AtomicLongArray and AtomicArray<T>.
The current set of functions is implemented via atomic arrays intrinsics (see KT-58360) and provides sequentially consistent memory ordering guarantees and no spurious failures in compareAndSet/compareAndExchange operations.
For details see: KT-60608
Merge-request: KT-MR-11071
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
Replace `#include <inttypes.h>` with `cinttypes`.
Improve other includes in the same file.
^KT-58864
Co-authored-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Supported atomic update of elements for IntArray, LongArray and Array<T>
See KT-58360
Merge-request: KT-MR-11020
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
This avoids that the thread sweeping the base object can get stale
locals, in the case that the finalizer thread unlinks the extraobject at
the same time. This is done by moving the responsibility of unlinking
the extraobject to the sweeping of the base object.
Co-authored-by: Troels Bjerre Lund <troels@google.com>
Merge-request: KT-MR-10518
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
Currently, if a Kotlin object happens to have null for an associated
object but FLAGS_RELEASE_ON_MAIN_QUEUE flag set, GC will dispatch
Kotlin_ObjCExport_releaseAssociatedObject(null) to the main thread
anyway.
This couldn't happen before, but can now, with disposeObjCObject.
The commit prevents this, by moving the null check out from
Kotlin_ObjCExport_releaseAssociatedObject to call sites.
^KT-59134
For a Kotlin wrapper of an Objective-C object, this functions zeroes
and releases the strong reference from the Kotlin wrapper to the
Objective-C object.
Usually, such a release happens only when the Kotlin wrapper is GCed.
So using this function can help that happen sooner.
^KT-59134
Before this change `./gradlew help` (with native enabled)
Created immediately: 1322
Created during configuration: 1541
after this change:
Created immediately: 596
Created during configuration: 1509
To know more about configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
Because the overload has a meaningful implementation only in JVM.
In other platforms the specified lock object is ignored.
In K/N it throws UnsupportedOperationException.
Alexander Shabalin