Skip to content

1.x: proposal: onTerminateDetach - detach upstream/downstream for GC #3888

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

Merged
merged 1 commit into from
May 3, 2016

Conversation

akarnokd
Copy link
Member

By default, operators have final link to their child Subscriber and they never clear the upstream's Producer. If the end subscriber is referenced, for example in a CompositeSubscription, that keeps an entire chain of objects alive and can cause memory leaks (a use case common on Android).

This proposed operator detaches the structures and nulls out references if the sequence terminates or the downstream unsubscribes - at the cost of atomic operations and mandatory volatile read for each onNext().

I know this issue has been brought up several times, but instead of adding the overhead to every operator, I propose an operator that can be applied when the developer really needs it (i.e., could be part of the usual compose(subscribeOn/observeOn) setup).

On the implementation side, this requires deferred Producer/request() handling because requests from downstream may appear even before the upstream calls setProducer (if at all) and we can't use the base class' behavior for this.

o = null;

System.gc();
Thread.sleep(200);
Copy link
Member

Choose a reason for hiding this comment

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

I believe that on most JVM implementations, the sleep is useless.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know, calling gc() is not dependable but I don't know any other way of detecting leaks as small as this.

@stevegury
Copy link
Member

👍

@akarnokd akarnokd merged commit 4e5c17c into ReactiveX:1.x May 3, 2016
@JakeWharton
Copy link
Contributor

Doesn't proper Subscription nulling and/or CompositionException clearing solve this? I haven't seen a lot of people complaining about leaks recently. Is something motivating this?

@akarnokd akarnokd deleted the OnTerminateDetach branch May 3, 2016 20:16
@akarnokd
Copy link
Member Author

akarnokd commented May 3, 2016

What I've seen in Android examples, is that you add to a composite on creation and clear() the composite on destroy, but haven't seen the subscriber removed from the composite when it finishes normally but still while the activity is active.

@JakeWharton
Copy link
Contributor

Ah, I see. And that leaks the observable itself, not the activity.

On Tue, May 3, 2016 at 4:18 PM David Karnok notifications@github.com
wrote:

What I've seen in Android examples, is that you add to a composite on
creation and clear() the composite on destroy, but haven't seen the
subscriber removed from the composite when it finishes normally but still
while the activity is active.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#3888 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants