Управление памятью в Kotlin/Native

Kotlin/Native использует современный менеджер памяти, аналогичный JVM, Go и другим распространённым технологиям:

Объекты хранятся в общем куче и могут быть доступны из любого потока.
Периодически выполняется сборка мусора (GC), чтобы очистить объекты, недоступные из «корней», таких как локальные и глобальные переменные.

Менеджер памяти одинаков на всех целевых платформах Kotlin/Native, за исключением wasm32, который поддерживается только в устаревшем менеджере памяти.

Сборщик мусора

Точный алгоритм GC постоянно развивается. По состоянию на 1.7.20, это сборщик мусора Stop-the-World Mark and Concurrent Mark Sweep, который не разделяет кучу на поколения.

GC выполняется в отдельном потоке и запускается на основе таймера и эвристики по давлению памяти, или может быть вызван вручную.

Включение сборки мусора вручную

Для принудительного запуска сборщика мусора, вызовите kotlin.native.internal.GC.collect(). Это запускает новую сборку и ожидает её завершения.

Мониторинг производительности GC

Пока нет специальных инструментов для мониторинга производительности GC. Однако всё ещё можно просмотреть логи GC для диагностики. Для включения логгирования установите соответствующий флаг компиляции в скрипте сборки Gradle:

-Xruntime-logs=gc=info

В настоящее время логи выводятся только в stderr.

Отключение сборки мусора

Рекомендуется держать GC включённым. Однако в некоторых случаях, например, для тестирования или если у вас кратковременная программа, вы можете его отключить. Для этого установите соответствующий флаг компиляции в скрипте сборки Gradle:

-Xgc=noop

Потребление памяти

Если в программе нет утечек памяти, но вы всё ещё видите неожиданно высокое потребление памяти, переключите аллокатор памяти с mimalloc, который используется по умолчанию на многих платформах, на системный. Для этого установите соответствующий флаг компиляции в скрипте сборки Gradle:

-Xallocator=std

Если потребление памяти снизится до ожидаемого уровня, всё в порядке. Аллокатор mimalloc предварительно выделяет системную память для повышения производительности.
Если потребление памяти по-прежнему не снижается, сообщите об ошибке в YouTrack.

Тестирование в фоновом режиме

В тестах ничего не обрабатывает очередь главного потока, поэтому не используйте Dispatchers.Main если оно не было смоделировано, что можно сделать, вызвав Dispatchers.setMain из kotlinx-coroutines-test.

Если вы не полагаетесь на kotlinx.coroutines или Dispatchers.setMain по какой-то причине не работает для вас, попробуйте следующее решение для реализации загрузчика тестов:

package testlauncher import platform.CoreFoundation.* import kotlin.native.concurrent.* import kotlin.native.internal.test.* import kotlin.system.* fun mainBackground(args: Array<String>) { val worker = Worker.start(name = "main-background") worker.execute(TransferMode.SAFE, { args.freeze() }) { val result = testLauncherEntryPoint(it) exitProcess(result) } CFRunLoopRun() error("CFRunLoopRun should never return") }

Затем скомпилируйте бинарник теста со флагом компилятора -e testlauncher.mainBackground.

Устаревший менеджер памяти

Если необходимо, можно вернуться к устаревшему менеджеру памяти. Установите соответствующий параметр в gradle.properties:

kotlin.native.binary.memoryModel=strict

Если у вас возникли проблемы с миграцией с устаревшего менеджера памяти или вы хотите временно поддерживать как текущий, так и устаревший менеджеры памяти, см. наши рекомендации в руководстве по миграции.

Что дальше

Последнее изменение: 22 сентября 2022

© 2010–2022 JetBrains s.r.o. and Kotlin Programming Language contributors
Licensed under the Apache License, Version 2.0.
https://kotlinlang.org/docs/native-memory-manager.html