-
Notifications
You must be signed in to change notification settings - Fork 215
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
remove gcEveryCrank
and worker type xs-worker-no-gc
#5600
Labels
Comments
warner
added a commit
that referenced
this issue
Jun 29, 2022
These had bitrotted: * transcript now includes whole syscall result, even failures * handle kerneldb bundleIDs * new LMDB in swingstore * gcEveryCrank=false else all GC is disabled (refs #5600) * fake kernelKeeper/slogger needed new methods The new code also attempts to track `deliveryNum`, to align it with the original slog, but I'm not positive it is accurate. closes #5602
warner
added a commit
that referenced
this issue
Jun 29, 2022
These had bitrotted: * transcript now includes whole syscall result, even failures * handle kerneldb bundleIDs * new LMDB in swingstore * gcEveryCrank=false else all GC is disabled (refs #5600) * fake kernelKeeper/slogger needed new methods The new code also attempts to track `deliveryNum`, to align it with the original slog, but I'm not positive it is accurate. closes #5602
warner
added a commit
that referenced
this issue
Jun 30, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
warner
added a commit
that referenced
this issue
Jul 3, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
warner
added a commit
that referenced
this issue
Jul 6, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
warner
added a commit
that referenced
this issue
Jul 7, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
warner
added a commit
that referenced
this issue
Jul 7, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
warner
added a commit
that referenced
this issue
Jul 9, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
turadg
pushed a commit
that referenced
this issue
Jul 14, 2022
While we were debugging performance problems last year, we introduced `managerType: 'xs-worker-no-gc'`, which is a variant of `xs-worker` that disables the forced GC we were doing at the end of every delivery. Since then, we've improved performance in several ways: * XS bugs were retaining objects, which have since been fixed * we only do a forced GC during special `dispatch.bringOutYourDead` cranks * we deliver BOYD less often (according to a configurable schedule, see #4160 for our decisions, but we're thinking once every 100 to 1000 deliveries) The `xs-worker-no-gc` manager type controlled a flag named `gcEveryCrank`, which replaced the GC primitive available to liveslots with a dummy version. This commit removes both `xs-worker-no-gc` and `gcEveryCrank`. closes #5600
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
A long while ago, before we introduced
dispatch.bringOutYourDead
, liveslots did a forced GC at the end of every crank. in a panic to improve performance during one of the incentivized testnet runs, we introduced a quick hack whereinmanagerType: 'xs-worker-no-gc'
would use a newgcEveryCrank: false
flag to replace the normalgcAndFinalize
with a dummy version, thus disabling GC entirely.Now that we have configurable scheduling for BOYD, and GC is only forced during BOYD, we don't need this mechanism anymore.
Description of the Design
I count 8 files that reference either
gcEveryCrank
orxs-worker-no-gc
:The task is to remove references to both, making
gcAndFinalize
be always the real function.Security Considerations
When GC is disabled in this way, it prevents BOYD from doing a forced GC, but it doesn't prevent organic GC from happening. If we allow organic GC to happen on different schedules in different validators (which used to be a goal, but #5564 discusses why I think we should disallow it), the lack of a forced GC would probably cause GC syscalls to happen later than usual, which could then turn into a consensus break.
The lack of forced GC probably wouldn't affect the risk of worker memory exhaustion very much, because organic GC keeps happening.
managerType: xs-worker-no-gc
is currently the only way that a dynamic vat creator has to disable forced GC. BOYD scheduling can be controlled (or effectively disabled) by the host application, throughcontroller.changeKernelOptions()
, but the per-vat admin facet does not provide that authority.So I'd argue that security is marginally better without
xs-worker-no-gc
.Test Plan
The existing unit tests are probably sufficient, because we never got around to adding a test for
xs-worker-no-gc
anyways.The text was updated successfully, but these errors were encountered: