exported object ID counter vs upgrade

[warner]

What is the Problem Being Solved?

While reviewing @gibson042 's #4717, I realized that liveslots keeps the "next exported object ID counter" in RAM (nextExportID and nextPromiseID, via allocateExportID() and allocatePromiseID()). That's fine for a single vat-version lifetime, but when the vat is upgraded, those RAM counters will be reset, and the vat will start exporting new objects (and promises) from o+1 and p+1.

That means the new vat-version will export objects that collide with their earlier exports. We might terminate all non-durable object exports during upgrade (I'm still undecided whether vats should reconnect their "precious" Far/Remotable exports, or if they should be terminated), which might reduce the scope of the problem, but I think we still use that counter to allocate the base vref for new virtual/durable Kinds, and we need that to not collide.

Promises are troublesome too. Half of them aren't a problem: we intend to reject all outstanding promises during upgrade, so we'll remove them from the upgraded vat's c-list (the kernel rejects them, so vat-version2 doesn't need to, so it doesn't even need to reference them, and there are not references to them in durable data so vat-version2 doesn't need to be told about them either).

But that's determined by the decider, not the vpid allocator. If vat-version1 sent a message and attached a result promise vref of p+1, then that's going to be decided by some other vat, and so we won't reject it when the sending vat is upgraded. What we can do is remove the upgraded vat from the subscribers list, so it won't receive notifications of resolution, so it won't be a problem that the kpid is missing from the c-list. That sounds expensive, though: we have an index from kpid to subscribing VatIDs, but nothing mapping VatID to a list of subscribed promises. So maybe we should leave the upgraded vat in the subscribing list, but delete all c-list entries involving promises. When the notification arrives, handleNotify will see that the kpid is missing from the c-list, and conclude that the vat had already received the message somehow (batched resolutions can cause this).

Ok, so nextPromiseID isn't a problem: the c-list seen by vat-version2 will be entirely devoid of promise references.

But nextExportID might. The fix is to keep it in the vatStore, durably, but that sounds expensive too.

It's starting to sound like a pre-upgrade "cache flush" step would be convenient. We already plan to do a bringOutYourDead before upgrade, to write out the virtual object cache. Maybe we should write nextExportID to the vatStore at the same time? Kinda gross but maybe ok.

cc @FUDCo

Description of the Design

Security Considerations

Test Plan

[warner]

To unsubscribe the promises, we might also walk the upgraded vat's c-list during update, and examine the status of all promises it mentions as we remove them. If the promise is unresolved and the vat is a subscriber, remove it from the subscriber list. If the promise is unresolved and the vat is the decider, reject it. It might be both.

[FUDCo]

We already have a bunch of this kind of thing going on in the kernel, so I don't know that using the DB for this will appreciably add to the load. Certainly we can use a write-thru cache to replace the read-modify-write cycle with a simple write, and I think with a little bit of additional cleverness we can arrange to have that write happen at most once per crank.