-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[7/n][vm-rewrite][sui-execution] Update adapter #21071
base: tzakian/vm-rewrite-adapter-6
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
489397b
to
53ce0a8
Compare
4dde691
to
3c7de3c
Compare
53ce0a8
to
04ed3db
Compare
3c7de3c
to
eee4b44
Compare
04ed3db
to
89b34cf
Compare
eee4b44
to
6942570
Compare
89b34cf
to
208bdfc
Compare
6942570
to
4bd62dc
Compare
This is the big one... There is still some refactoring and changes need, but broad-strokes this plumbs in the new VM to the adapter. The main conceptual change is the idea of a `LinkedContext` which is an execution context with a specific linkage and VM instance associated with it. All commands currently require a `LinkedContext`. On the TODO list is: 1. To relax the need for a `LinkedContext` for `Upgrade` and `Publish` commands to require a context a priori (however there are some mechanics that will need to be sorted out to make this work). 2. Properly handle type versioning/defining IDs for typetags/type resolution. 3. General cleanup. NB: The code in the PR may not be working as future PRs will build on top of this.
208bdfc
to
3f44124
Compare
4bd62dc
to
c6641eb
Compare
/// Newly published packages | ||
new_packages: Vec<MovePackage>, | ||
pub new_packages: Vec<MovePackage>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please no pub
here. Bad things can happen if this is pub
--very delicate code
/// A "reverse" linkage of storage_id -> runtime_id | ||
pub reverse_linkage: BTreeMap<ObjectID, ObjectID>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why isn't this a part of ResolvedLinkage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No particular reason, I think adding in to that would make sense to me.
)?; | ||
let reverse_linkage = linkage | ||
.iter() | ||
.map(|(k, v)| (*v, *k)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this guaranteed to be bidirectional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we are guaranteed that every version of a package corresponds to exactly one original package id (i.e., package UUID).
Basically, if there were a conflict here it would mean that package A@v1
is somehow both a A@v1
and a B@v_something
package which is impossible.
This is the big one...
There is still some refactoring and changes need, but broad-strokes this plumbs in the new VM to the adapter.
The main conceptual change is the idea of a
LinkedContext
which is an execution context with a specific linkage and VM instance associated with it. All commands currently require aLinkedContext
.On the TODO list (but for other PRs) is:
LinkedContext
forUpgrade
andPublish
commands to require a context a priori (however there are some mechanics that will need to be sorted out to make this work).