feat: ResourceManager (tracing GC approach) #9612
Draft
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.
this is exploration for an RFC exploring the idea pitched in #8162
see also #9518 for V3 Cache spec exploration which this would tie into.
I'm about 70% confident in the approach I've laid out being viable without mucking with performance too much, but proof will be in the pudding as they say.
An alternative is to only trigger GC on request dismount, either still via WeakRef or by explicit ref counting via Request component usage or early adoption of the explicit resource management API: but that would force everyone into a less flexible set of patterns which would be not-useful. We'd also have to assume every record was always a potential candidate in this alternative case, though the initial weed-out would likely be quick in the first pass. WeakRef only for requests + iterate all resources vs just marked ones may be just as good an outcome overall though. What it lacks is the safety of not eliminating records that users have either accidentally or intentionally retained in their components.