kernel parameter configuration API and chain-side controls

[warner]

What is the Problem Being Solved?

We have a couple of kernel parameters that may need to be tuned after launch, as we learn more about the way things perform. We expect to have more in the future.

• reapInterval aka BOYD aka BringOutYourDead timing: Performance impact of BOYD #4160 is about choosing the initial value
• virtual object cache size: increase swingset DEFAULT_VIRTUAL_OBJECT_CACHE_SIZE #2644
• vat-warehouse heap-snapshot interval
• message size limit: impose configurable hard limit on message sizes #4280 is about implementing one, but the size then needs to be configurable
• kernel run-queue size influencing cosmic-swingset message admission (maybe increasing minimum gas price, maybe blocking messages entirely)

For all of these knobs, we need a plan for how they'll be changed after launch.

Some of them are currently stored in the DB, separately, for each vat. Some are (or will be) kernel-wide. Most do not yet have APIs to change them. We could add new methods to vatAdminService to change them from within JS, in which case the "Big JS Hammer" (bootstrap.js) upgrade method would be the governance mechanism that do the changes. For the per-vat items, we could methods to each vat's adminFacet to manipulate the values, which might allow Zoe to make the changes.

Or, we could add controller.* methods to changes things. That would leave cosmic-swingset holding the controls, and would require some cosmos-side governance mechanism to control them.

Some of these parameters might be needed to pause (or unpause) Swingset entirely. Once Swingset is paused or broken somehow, we won't be able to get a message to JS, so the unpause button must be invoked by the cosmos side.

We need both kernel-provided control APIs, and code within contracts or cosmic-swingset that will use these APIs upon completion of some kind of governance action.

Description of the Design

TBD

Security Considerations

Test Plan

[Tartuffo]

Have to determine for each param:

1. Do we want to control it.
2. kernel side controls
3. cosmic swingset side controls.

@warner and @JimLarson should discuss further.

Would prefer to have Cosmic Swingset control this, not Zoe.

[warner]

@FUDCo will start work on the swingset side of this. Some of these parameters are stored on a per-vat basis, and should probably be controlled through each vat's admin facet. Chip warns against using a bunch of tiny one-parameter methods (e.g. E(adminFacet).setReapInterval(newInterval), etc), and instead recommends a single changeOptions method that can set several things at once (and leaves a value unchanged if you don't name it in the argument). So E(adminFacet).changeOptions({ reapInterval: newInterval, snapshotInterval: newSI }). This changeOptions should reject any options that cannot be updated (yet).

Ideally, E(adminFacet).upgrade(newBundleCap, options) would provide another opportunity to change options. Currently upgrade only accepts options.vatParameters, but with a little work we could provide more.

• reapInterval: this is stored as a VatKeeper DB entry for each vat, and I think it's queried on each delivery, so it might not require anything more than modifying the kvStore
• virtualObjectCacheSize: this is currently provided to buildLiveslots exactly once per version. We might decide 1: you don't get to change it after createVat, 2: you can change it with upgrade(newBundleCap, { virtualObjectCacheSize: newSize }) but not with anything smaller, or 3: you can change it with changeOptions. To support 3 we'd need to add something like dispatch.setOptions({ virtualObjectCacheSize }).
• heapSnapshotInterval: I know vat-warehouse tracks this, but I don't know if it's per-vat or warehouse-wide. If it's per-vat, then changeOptions should be a valid way to control it.

Anything that we can control with E(adminFacet) can be managed by the Big JS Hammer, so once swingset has provided the necessary controls, we don't need to do anything else (on the chain side). A future Big JS Governance Hammering action can evaluate code in the bootstrap environment that uses the stashed admin facets to call changeOptions.

The other options are kernel-wide, e.g. I don't think we'll provide a per-vat maximum syscall.send message size limit. That means controller.something() is the right place to control them. Chip's argument applies here too: instead of a discrete controller.setMaxMessageSize(newSize), we probably want controller.changeOptions({ maxMessageSize }). Ideally this function should take option names that exactly match the ones provided at initialization time.. defaultManagerType is the only one I'm seeing now (and I don't think we need to let that be changed). But when we add maxMessageSize, we should probably add it to both initializationOptions and changeOptions().

For any parameters that are managed through controller.changeOptions(), the Big JS Hammer won't help to control them, because that hammer lives inside a vat, and controller is not available there. Instead, we'll need to add something to cosmic-swingset to allow certain cosmos messages (governance actions) invoke the controller method.

@FUDCo 's first task here is to identify the things we might need to change, and provide a swingset control mechanism for each. Then he'll coordinate with @JimLarson to make sure the non-Big-JS-Hammer ones have a suitable cosmos-activated invocation path.