-
Notifications
You must be signed in to change notification settings - Fork 232
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
Garbage collect resolved promises #1124
Comments
@FUDCo 's current efforts are towards retiring the c-list entries for all resolved promises, performing the resolution in a batch so that any inter-promise references are available before their identifiers disappear. We have three phases of this work:
Retiring c-list entries is the first step. Once all c-list references to a kernel promise table entry are gone, we can check to see if anything else within the kernel is still referencing the promise (run-queue entries, resolution data for other promises, messages within other promises, auxiliary kernel object data). If all other references are gone, we can deallocate the orphaned promise table entry (and save the kernel DB space it consumed). There may be collectable cycles in the graph, which will require more sophisticated tools to collect safely. The simplest case is when some number of resolved promises reference each other, but nothing else references them. |
The remaining portion of this ticket is covered by #1126, so I'm closing this one. |
This issue summarizes subtasks related to the garbage collection of promises that resolve to data containing references to other promises. It is a tracking issue derived from the discussion in #1049 that produced a plan for doing this. There are various tickets related to retiring resolved promises that were collectively tracked by #675, but that although that issue both contains and points to a lot of relevant background, as a planning document it has drifted out of relevance as our understanding of the underlying problem has evolved and as various elements of the solution have been implemented and merged into the main trunk of development.
The current breakdown of subtasks is:
Note that both the open issues above have a kernel portion and a liveslots portion, which, while they'll likely be implemented separately, will need to be coordinated so that there is no inconsistency between the kernel's and the vats' views of the world.
The text was updated successfully, but these errors were encountered: