Skip to content

Cleanup continuation field in lazily-started coroutines after the start to reduce potential memory pressure #2511

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

Closed
wants to merge 4 commits into from

Conversation

qwwdfsad
Copy link
Collaborator

@qwwdfsad qwwdfsad commented Feb 1, 2021

Also, as long as onStart is our own private API, replace checkNotNull with !! operator to save few bytecodes

@qwwdfsad qwwdfsad requested a review from elizarov February 1, 2021 15:15
@qwwdfsad
Copy link
Collaborator Author

qwwdfsad commented Feb 1, 2021

Also, I've found that lazy broadcast is broken, but decided not to touch it because we are planning to deprecate it pretty soon anyway

1zaman and others added 4 commits February 1, 2021 18:16
When starting a coroutine lazily by using CoroutineStart.LAZY, it
creates a Continuation that would launch the coroutine block, which is
stored in the returned Job or Deferred to be invoked lazily. However,
this reference is never cleared, even after the coroutine ends.

This prevents the coroutine block and it's enclosing class instance from
being garbage collected if the Job or Deferred is retained in another
class, or while child coroutines are running (as they also hold a
reference to the Job).

Fixed by clearing the reference to the Continuation after invoking it.
…rt to reduce potential memory pressure

Also, as long as onStart is our own private API, replace checkNotNull with !! operator to save few bytecodes
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.

2 participants