Coroutines debugger should keep weak references to running coroutines (#2129)

It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases:
* Synchronous coroutines (iterator/sequence).
* Lazy coroutines that were not started.
* Abandoned coroutines that suspend forever without strong references to them in GlobalScope.

Two kinds of tests cover this functionality:
* A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere.
* A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests.

Fixes #2117
18 files changed
tree: 62c4deb3a4bef02d2b8f52227684cafcb9df4f95
  1. .idea/
  2. benchmarks/
  3. buildSrc/
  4. docs/
  5. gradle/
  6. integration/
  7. integration-testing/
  8. js/
  9. kotlinx-coroutines-bom/
  10. kotlinx-coroutines-core/
  11. kotlinx-coroutines-debug/
  12. kotlinx-coroutines-test/
  13. license/
  14. reactive/
  15. site/
  16. stdlib-stubs/
  17. ui/
  18. .gitignore
  19. build.gradle
  20. bump-version.sh
  21. CHANGES.md
  22. CODE_OF_CONDUCT.md
  23. coroutines-guide.md
  24. gradle.properties
  25. gradlew
  26. gradlew.bat
  27. LICENSE.txt
  28. README.md
  29. RELEASE.md
  30. settings.gradle
README.md

kotlinx.coroutines

official JetBrains project GitHub license Download

Library support for Kotlin coroutines with multiplatform support. This is a companion version for Kotlin 1.3.71 release.

suspend fun main() = coroutineScope {
    launch { 
       delay(1000)
       println("Kotlin Coroutines World!") 
    }
    println("Hello")
}

Play with coroutines online here

Modules

Documentation

Using in your projects

The libraries are published to kotlinx bintray repository, linked to JCenter and pushed to Maven Central.

Maven

Add dependencies (you can also add other modules that you need):

<dependency>
    <groupId>org.jetbrains.kotlinx</groupId>
    <artifactId>kotlinx-coroutines-core</artifactId>
    <version>1.3.7</version>
</dependency>

And make sure that you use the latest Kotlin version:

<properties>
    <kotlin.version>1.3.71</kotlin.version>
</properties>

Gradle

Add dependencies (you can also add other modules that you need):

dependencies {
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7'
}

And make sure that you use the latest Kotlin version:

buildscript {
    ext.kotlin_version = '1.3.71'
}

Make sure that you have either jcenter() or mavenCentral() in the list of repositories:

repository {
    jcenter()
}

Gradle Kotlin DSL

Add dependencies (you can also add other modules that you need):

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7")
}

And make sure that you use the latest Kotlin version:

plugins {
    kotlin("jvm") version "1.3.71"
}

Make sure that you have either jcenter() or mavenCentral() in the list of repositories.

Multiplatform

Core modules of kotlinx.coroutines are also available for Kotlin/JS and Kotlin/Native. In common code that should get compiled for different platforms, add dependency to
kotlinx-coroutines-core-common
(follow the link to get the dependency declaration snippet).

Android

Add kotlinx-coroutines-android module as dependency when using kotlinx.coroutines on Android:

implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.7'

This gives you access to Android Dispatchers.Main coroutine dispatcher and also makes sure that in case of crashed coroutine with unhandled exception this exception is logged before crashing Android application, similarly to the way uncaught exceptions in threads are handled by Android runtime.

R8 and ProGuard

R8 and ProGuard rules are bundled into the kotlinx-coroutines-android module. For more details see “Optimization” section for Android.

JS

Kotlin/JS version of kotlinx.coroutines is published as kotlinx-coroutines-core-js (follow the link to get the dependency declaration snippet).

You can also use kotlinx-coroutines-core package via NPM.

Native

Kotlin/Native version of kotlinx.coroutines is published as kotlinx-coroutines-core-native (follow the link to get the dependency declaration snippet).

Only single-threaded code (JS-style) on Kotlin/Native is currently supported. Kotlin/Native supports only Gradle version 4.10 and you need to enable Gradle metadata in your settings.gradle file:

enableFeaturePreview('GRADLE_METADATA')

Since Kotlin/Native does not generally provide binary compatibility between versions, you should use the same version of Kotlin/Native compiler as was used to build kotlinx.coroutines.

Building

This library is built with Gradle. To build it, use ./gradlew build. You can import this project into IDEA, but you have to delegate build actions to Gradle (in Preferences -> Build, Execution, Deployment -> Build Tools -> Gradle -> Runner)

Requirements

  • JDK >= 11 referred to by the JAVA_HOME environment variable.
  • JDK 1.6 referred to by the JDK_16 environment variable. It is okay to have JDK_16 pointing to JAVA_HOME for external contributions.
  • JDK 1.8 referred to by the JDK_18 environment variable. Only used by nightly stress-tests. It is okay to have JDK_18 pointing to JAVA_HOME for external contributions.

Contributions and releases

All development (both new features and bug fixes) is performed in develop branch. This way master sources always contain sources of the most recently released version. Please send PRs with bug fixes to develop branch. Fixes to documentation in markdown files are an exception to this rule. They are updated directly in master.

The develop branch is pushed to master during release.

  • Full release procedure checklist is here.
  • Steps for contributing new integration modules are explained here.
  • Use Knit for updates to documentation:
    • In project root directory run ./gradlew knit.
    • Commit updated documents and examples together with other changes.
  • Use Binary Compatibility Validator for updates to public API:
    • In project root directory run ./gradlew apiDump.
    • Commit updated API index together with other changes.