4.x: Cache/Replay operators to be more GC friendly
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 48.2k
- Forks
- 7.6k
- Avg merge
- 39m
- Merged PRs (30d)
- 11
Description
⚠️ Due to the unexpectedly long time this issue was up, we require you to target 4.x first and we'll see if it is worth backporting it to an earlier version.
The current implementations of the various cache and replay operators and hot sources can hold onto effectively unreachable elements longer than necessary, causing GC pressure with certain collectors.
The following operators need to be checked and updated.
-
ObservableCache -
FlowableCache -
ObservableReplay -
FlowableReplay -
ReplaySubject -
ReplayProcessor
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the checked ObservableCache implementation with the remaining FlowableCache, ObservableReplay, FlowableReplay, ReplaySubject, and ReplayProcessor operators. Trace how each retains elements and identify the cases described as effectively unreachable. Done means the remaining operators have been updated for reduced GC pressure and their behavior remains correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100