-
Notifications
You must be signed in to change notification settings - Fork 215
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(swingset): initializeStoreKindInfo() earlier, unconditionally
The liveslots "collection manager" assigns a virtual-object Kind ID to each of the collection types it supports. Currently there are 8: (weak vs strong) times (map vs set) times (virtual vs durable). These Kind IDs live in the same numberspace as the virtual/durable Kinds that userspace creates by calling `defineKind` or `defineDurableKind`. This numberspace is also used for Export IDs, the `o+NN` values assigned to exported Remotables. Previously, the Kind IDs for the collections were allocated on-demand, the first time anybody created a collection. The IDs they got could vary, depend upon whether userspace created a collection first, or used `defineKind` first. This also changed when we introduced "baggage" (which is a durable collection, created by liveslots itself). This commit moves the allocation step: it is now done unconditionally during startVat(), before userspace gets control. This should make the allocated IDs more consistent across all vats. This should behave correctly when we add new kinds of Stores in the future: when the vat is upgraded to a new liveslots, it will read the existing IDs from the DB, add any new ones, then write the updated table back to the DB. As a side-effect of this change, *all* vats now have kvStore keys to record the IDs, not just the once which use collections. And the first Export ID allocated after startup (either an object export or a Kind definition) will get a different ID: instead of `o+1`, it is likely to be `o+9`. Several unit tests needed to be updated as a result, however now they won't have to be updated further if e.g. `startVat` changes to create collections before userspace runs.
- Loading branch information
Showing
7 changed files
with
184 additions
and
162 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.