From 0b431d5ea5ec7e6d0847652dbd52d7bacdc50d17 Mon Sep 17 00:00:00 2001 From: Alexander Shabalin Date: Tue, 14 Sep 2021 14:00:46 +0000 Subject: [PATCH] [K/N] Link GC triggers issue --- kotlin-native/NEW_MM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kotlin-native/NEW_MM.md b/kotlin-native/NEW_MM.md index 95fb4ed501e..a3cac7731ca 100644 --- a/kotlin-native/NEW_MM.md +++ b/kotlin-native/NEW_MM.md @@ -123,7 +123,7 @@ The list of known performance issues: * Being stop-the-world also means that all threads with Kotlin/Native runtime active on them need to synchronize simultaneously for the collection to begin. This also affects the pause time. * There is a complicated relationship between Swift/ObjC objects and their Kotlin/Native counterparts, which causes Swift/ObjC objects to linger longer than necessary. It means that their Kotlin/Native counterparts are kept in the heap longer, contributing to the slower collection time. This typically doesn't happen, but in some corner cases, for example, when a long loop creates several temporary objects that cross the Swift/ObjC interop boundary on each iteration (for example, calling a Kotlin callback from a loop in Swift or vice versa). In the logs, there's a number of stable refs in the root set. If this number keeps growing, it may indicate that the Swift/ObjC objects are not being freed when they should. Try putting `autoreleasepool` around loop bodies (both in Swift/ObjC and Kotlin) that do interop calls. -* Our GC triggers do not adapt to the workload: collections may be requested far more frequently than necessary, which means that GC time may dominate useful application run time and pause the threads more frequently than needed. +* [(YouTrack issue)](https://youtrack.jetbrains.com/issue/KT-48537) Our GC triggers do not adapt to the workload: collections may be requested far more frequently than necessary, which means that GC time may dominate useful application run time and pause the threads more frequently than needed. This manifests in time between cycles being close (or even less) than the pause time. Both of these numbers are printed to the logs. Try increasing `kotlin.native.internal.GC.threshold` and `kotlin.native.internal.GC.thresholdAllocations` to force GC to happen less often. Note that the exact meaning of `threshold` and `thresholdAllocations` may change in the future. * Freezing is currently implemented suboptimally: internally, a separate memory allocation may occur for each frozen object (this recursively includes the object subgraph), which puts unnecessary pressure on the heap.