Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coroutines debugger should keep weak references to running coroutines #2129

Merged
merged 9 commits into from Jul 16, 2020

Conversation

elizarov
Copy link
Contributor

@elizarov elizarov commented Jul 8, 2020

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

@elizarov elizarov requested a review from qwwdfsad July 8, 2020 22:10
@elizarov elizarov force-pushed the debugger-leak branch 3 times, most recently from a752e35 to 43e6e23 Compare July 8, 2020 22:33
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
…ying on hardcoded period

Also, don't check ref queue on every put (not needed in practice)
@elizarov elizarov requested a review from qwwdfsad July 16, 2020 16:21
@elizarov elizarov mentioned this pull request Jul 16, 2020
1 task
Copy link
Member

@qwwdfsad qwwdfsad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM module proposed changes

@elizarov elizarov merged commit c05de88 into develop Jul 16, 2020
@elizarov elizarov deleted the debugger-leak branch July 16, 2020 20:34
recheej pushed a commit to recheej/kotlinx.coroutines that referenced this pull request Dec 28, 2020
…Kotlin#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 Kotlin#2117
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants