prepare for GC: several kernel refactorings #3225
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b017803 to
5513673
Compare
5502caa to
5581286
Compare
5513673 to
1701efa
Compare
FUDCo
approved these changes
Jun 3, 2021
To simplify kernelKeeper, I'm going to remove its tolerance for spurious calls (when the `kref` argument it receives is `undefined`). To prepare, this changes the two places that previously might have called it with `undefined` to refrain from calling it all all in that case. refs #2946
The c-list kernel-to-vat direction uses a value that holds a composite of a "isReachable" flag and the actual vref. This refactors the handling of this composite value to make it easier for upcoming code to query the isReachable status. refs #3108
The kernelKeeper `addKernelObject` method was updated to accept an `id=` override, to simplify some upcoming unit tests. `deleteKernelObject` was added, which isn't called yet but the upcoming GC changes will invoke it when GC allows a kernel object to be deleted. It's also a placeholder for #2069 auxdata to be deleted.
5581286 to
9cccd6e
Compare
1701efa to
551e07a
Compare
This function takes an object kref and returns a list of vatIDs which have imported that object. As mentioned in #3223, this would be more efficient with an index.
Rather than going directly to the run-queue, this changes `kernel.step()` and `kernel.run()` to use a new `getNextMessage()` function. This will give us a clean place to sample the new (higher-priority) GC Actions queue before inspecting the run-queue. For now, no behavior is changed.
Many operations that previously finished in a single crank will start to need additional cranks soon, when we begin processing GC actions before servicing the run-queue. This patch anticipates these new GC actions by changing several tests to use `c.run()` (which drains both queues) instead of `c.step()` which does just a single crank).
551e07a to
0e7676b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 refactors a number of kernel pieces in preparation for landing GC features. I recommend reviewing this one commit at a time.
decrementRefCounta message result promise if we know the value isundefinedaddKernelObjectfor unit tests, and adddeleteKernelObjectkernelKeeper.getImporters(add kernelKeeper index to efficiently track the importing vats of each kernel object #3223 is the plan to make it better, but I think with <30 vats it's probably sufficient for the next few weeks)kernel.run()/step()to use a newgetNextMessage(), in preparation for executing GC actions before anything on the run-queuerefs #3106