fix(SwingSet): VOM tracks Presence vrefs in virtualized data #3157
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
warner
force-pushed
the
3133-track-virtualized-presences
branch
from
7154624 to
42b8a3e
Compare
FUDCo
approved these changes
May 25, 2021
package.json
Outdated
Comment on lines
90
to
92
| "nodeArguments": [ | ||
| "--expose-gc" | ||
| ], |
There was a problem hiding this comment.
Do you really want to enable this globally for all tests in the entire agoric-sdk or just for SwingSet? I can see there being an argument for the former; I just want to be sure it's deliberate.
There was a problem hiding this comment.
Unfortunately I don't have a choice: now that the top-level yarn test runs AVA directly (which enables more parallelism), it no longer consults the individual packages/*/package.json files: every test program in the entire monorepo gets the same set of flags.
Also, it's not a problem to expose gc to the start compartment of all programs.. it doesn't enable that code to anything worse than it could already do.
If userspace puts a Presence into the `state` of a virtual object, or somewhere inside the value stored in vref-keyed `makeWeakStore()` entry, it gets serialized and stored as a vref, which doesn't (and should not) keep the Presence object alive. Allowing this Presence to leave RAM, remembering only the vref on disk, is a non-trivial part of the memory savings we obtain by using virtualized data. However, just because there is currently no Presence (for a given vref) does *not* mean that the vat cannot reach the vref. Liveslots will observe the Presence being collected (when the finalizer runs), but if the vref is still stored somewhere in virtualized data, liveslots must not emit a `syscall.dropImport` for it. This changes the virtual object manager to keep track of Presences used in virtualized data, and remember their vref in a Set. When liveslots' wants to `dropImport` a vref that no longer has a Presence, it will ask the VOM first. With this Set, the VOM can inhibit the `dropImport` call until later. At this stage, we simply add the vref to a Set and never remove it. This is safe but conservative. In the future, we'll need some form of refcounting to detect when the vref is no longer mentioned anywhere in virtualized data. At that point, the VOM will need to inform liveslots (or some sort of "reachability manager") that the VOM no longer needs the vref kept alive. The `syscall.dropImport` can be sent when neither the VOM nor a Presence is causing the vref to remain reachable. closes #3133 refs #3106
warner
force-pushed
the
3133-track-virtualized-presences
branch
from
42b8a3e to
cb15717
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.
If userspace puts a Presence into the
stateof a virtual object, orsomewhere inside the value stored in vref-keyed
makeWeakStore()entry, itgets serialized and stored as a vref, which doesn't (and should not) keep the
Presence object alive. Allowing this Presence to leave RAM, remembering only
the vref on disk, is a non-trivial part of the memory savings we obtain by
using virtualized data.
However, just because there is currently no Presence (for a given vref)
does not mean that the vat cannot reach the vref. Liveslots will observe
the Presence being collected (when the finalizer runs), but if the vref is
still stored somewhere in virtualized data, liveslots must not emit a
syscall.dropImportfor it.This changes the virtual object manager to keep track of Presences used in
virtualized data, and remember their vref in a Set. When liveslots' wants to
dropImporta vref that no longer has a Presence, it will ask the VOM first.With this Set, the VOM can inhibit the
dropImportcall until later.At this stage, we simply add the vref to a Set and never remove it. This is
safe but conservative. In the future, we'll need some form of refcounting to
detect when the vref is no longer mentioned anywhere in virtualized data. At
that point, the VOM will need to inform liveslots (or some sort of
"reachability manager") that the VOM no longer needs the vref kept alive. The
syscall.dropImportcan be sent when neither the VOM nor a Presence iscausing the vref to remain reachable.
closes #3133
refs #3106