-
Notifications
You must be signed in to change notification settings - Fork 212
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
chore: provide GC tools (WeakRef/FinalizationRegistry) to makeLiveSlots #1924
Conversation
Hm, it looks like the test failures are because Node 12.x does not expose |
Based on our discussion, we're going to provide backwards compatibility with Node v12, which means the liveslots code will either get the real |
I'm going to change this to provide a no-op implementation under Node v12, I'll re-submit for review once that's done. |
The upcoming GC functionality will require `WeakRef` and `FinalizationRegistry`. Node.js v14 provides these as globals, but v12 does not (there might be a command-line flag to enable it, but I think it's marked as experimental). Rather than require all users upgrade to v14, we elect to disable GC when running on v12. This adds a local `weakref.js` module which attempts to pull `WeakRef` and `FinalizationRegistry` from the global, and exports either the real constructors or no-op stubs. refs #1872 refs #1925
These two authorities are not part of SES, so they must be pulled from the globals of the Start Compartment and ferried through the kernel to the vat manager factory that calls makeLiveSlots. This gives the outer layer of the vat (liveslots) access to nondeterminism. We rely upon liveslots to not share this power with the user-level ocap-style "vat code". Liveslots must never allow user-level code to observe behavior that depends upon GC activity, because that activity is not part of the specified input to the vat. refs #1872
@erights am I taming the generated stub object correctly? I don't know that I'm deleting the right |
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.
Looks fine, though I think we're going to want to do something about the proliferation of parameters to makeLiveSlots
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.
DO NOT MERGE THIS IN ITS CURRENT STATE. My review coming soon.
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.
Aside from my suggestions at #1931 , this LGTM
* fix: WeakRef taming follows taming pattern * fix: error message * fix: minor
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.
LGTM
These two authorities are not part of SES, so they must be pulled from the
globals of the Start Compartment and ferried through the kernel to the vat
manager factory that calls makeLiveSlots.
This gives the outer layer of the vat (liveslots) access to nondeterminism.
We rely upon liveslots to not share this power with the user-level ocap-style
"vat code". Liveslots must never allow user-level code to observe behavior
that depends upon GC activity, because that activity is not part of the
specified input to the vat.
These tools are not used by liveslots yet, that will come in a later PR.
refs #1872