2.x: Fix the extra retention problem in ReplaySubject #5892
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the bounded buffers of
ReplaySubject
, the head reference may retain one extra item when the trimming happens. Nulling out this reference is not possible at this point because old consumers may be still walking through the underlying linked list of nodes. However, replacing a head with the same next pointer (which is always not null if value is not null) but no value will eventually let the value get GCd. This cleanup doesn't happen on everyonNext
because it doubles the node allocation and thus the overhead.This PR modifies the code so that terminal events do perform this head swapping and introduces the
ReplaySubject.cleanupBuffer()
method to allow the user to perform the head swapping while theReplaySubject
is not yet terminated and the cleanup is needed.If this type of change is accepted, the
ReplayProcessor
can also be refitted. For thereplay()
operators, the terminal cleanup can be implemented but the on demand cleanup can't as there is no API surface for its internal buffer available.