Skip to content
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

feat: ResourceManager (tracing GC approach) #9612

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

runspired
Copy link
Contributor

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.

@runspired runspired added 🎯 canary PR is targeting canary (default) 🏷️ feat This PR introduces a new feature labels Nov 26, 2024
@runspired runspired self-assigned this Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🎯 canary PR is targeting canary (default) 🏷️ feat This PR introduces a new feature
Projects
Status: needs triage
Development

Successfully merging this pull request may close these issues.

1 participant