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

add stubs for GC syscalls/dispatches #2961

Merged
merged 1 commit into from
Apr 26, 2021
Merged

add stubs for GC syscalls/dispatches #2961

merged 1 commit into from
Apr 26, 2021

Conversation

warner
Copy link
Member

@warner warner commented Apr 26, 2021

This starts the process of #2724 GC work, with tolerated-but-ignored stubs for the new syscalls and dispatch objects.

@warner warner added the SwingSet package: SwingSet label Apr 26, 2021
@warner warner self-assigned this Apr 26, 2021
@warner warner force-pushed the 2724-gc-syscalls branch 2 times, most recently from 8031785 to 113da2d Compare April 26, 2021 16:37
@warner warner requested a review from FUDCo April 26, 2021 16:38
@warner
Copy link
Member Author

warner commented Apr 26, 2021

@FUDCo ready for review

There's one not-quite-related cleanup I bundled into this PR: removing most of the one-off methods in kernelSyscall.js. Once upon a time, this syscall object was exposed directly to vats, so it had separate methods for each of syscall.send, syscall.fulfillToData, etc. Now that we use a VatSyscallObject to represent these (vatManager/supervisor-helper.js provides the method-bearing syscall object to vat code, and translates their calls into VSOs), we no longer need the kernelSyscallHandler object to expose individual methods. Except for .send(), which is used in one place within the kernel (notifySubscribersAndQueue, to re-queue messages once their target promise becomes resolved). I suspect we'll leave send in place because rewriting that caller to do something else might not be a simplification, but maybe some future refactoring will make me think otherwise.

@warner warner force-pushed the 2724-gc-syscalls branch from 113da2d to 34ee911 Compare April 26, 2021 18:14
Copy link
Contributor

@FUDCo FUDCo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mahvelous.

This add `syscall.retireImports` and `syscall.retireExports` to the
pre-existing `syscall.dropImports`. All three are no-ops, but vats should be
able to call them without ill effects.

It also adds `dispatch.retireExports` and `dispatch.retireImports` to the
pre-existing `dispatch.dropExports` stub. These are tolerated but ignored by
both liveslots and the comms vat

Together, this should allow kernel and liveslots GC development to proceed in
parallel.

refs #2724
@warner warner force-pushed the 2724-gc-syscalls branch from 34ee911 to fa24bb9 Compare April 26, 2021 20:29
@warner warner merged commit fa24bb9 into master Apr 26, 2021
@warner warner deleted the 2724-gc-syscalls branch April 26, 2021 20:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SwingSet package: SwingSet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants