fix: liveslots: initialize counters in startVat, not on-demand #4926
Conversation
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
warner
force-pushed
the
1848-initialize-counters-earlier
branch
from
65ff42c to
db1ef0a
Compare
Liveslots maintains three counters: the Export ID (used for `o+NN` exported object vrefs), the Promise ID (for `p+NN` allocated promises), and the Collection ID (one per virtual/durable collection). Originally, these counters were only held in RAM: initialized during `makeLiveSlots()` and incremented when needed. To fix #4730, `makeLiveSlots()` was changed to read them from the DB, and then liveslots writes them back to the DB at the end of any delivery which modifies them. This ensures that a future version of the vat+liveslots can pick up allocation where the previous version left off. However the DB read to initialize the in-RAM copy did not set the 'dirty' flag. This caused variations in DB writes across different vats: `startVat` would not write out the initial values if `buildRootObject` did not happen to export any additional objects. In addition, since the DB value is a simple `JSON.stringify` of the counter record, the order of the keys varied depending upon whether an Object or Promise or Collection ID got allocated first. This commit changes the counter initialization process to use a fixed order for the counter names, and to always perform the initialization (and DB write) at the same time in all vats: during `startVat`, with a write at the end of the delivery. This should make the initial kvStore contents (just after `startVat`) more consistent. The new initialization code should behave correctly when we add new counters in the future: it will merge the new counter names (and initial values) into the record it reads from the DB during startVat. A handful of unit tests were updated to expect the new order.
warner
force-pushed
the
1848-initialize-counters-earlier
branch
from
db1ef0a to
700e2c2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Liveslots maintains three counters: the Export ID (used for
o+NNexported object vrefs), the Promise ID (for
p+NNallocatedpromises), and the Collection ID (one per virtual/durable
collection).
Originally, these counters were only held in RAM: initialized during
makeLiveSlots()and incremented when needed. To fix #4730,makeLiveSlots()was changed to read them from the DB, and thenliveslots writes them back to the DB at the end of any delivery which
modifies them. This ensures that a future version of the vat+liveslots
can pick up allocation where the previous version left off.
However the DB read to initialize the in-RAM copy did not set the
'dirty' flag. This caused variations in DB writes across different
vats:
startVatwould not write out the initial values ifbuildRootObjectdid not happen to export any additional objects. Inaddition, since the DB value is a simple
JSON.stringifyof thecounter record, the order of the keys varied depending upon whether an
Object or Promise or Collection ID got allocated first.
This commit changes the counter initialization process to use a fixed
order for the counter names, and to always perform the
initialization (and DB write) at the same time in all vats: during
startVat, with a write at the end of the delivery. This should makethe initial kvStore contents (just after
startVat) more consistent.The new initialization code should behave correctly when we add new
counters in the future: it will merge the new counter names (and
initial values) into the record it reads from the DB during startVat.
A handful of unit tests were updated to expect the new order.