basic VOM GC of reachable/recognizable objects (for Payments/Purses)

[warner]

What is the Problem Being Solved?

As described in #3106 (comment) , the next step of the GC task is to enable more (any) collection of objects that interact with the VirtualObjectManager (the VOM).

An object is reachable and recognizable by virtualized data if appears in a property of a virtual object, or as the value of a virtual weak store. Objects will be recognizable (but not reachable) if they appear as a key in a virtual weak store or a WeakMap/WeakSet (the values of a WeakMap/WeakSet are held in RAM, not virtualized, so we don't need to do anything special for them). The VOM manages all those things. If that object corresponds to a vref, and the normal JS Object stand-in for that vref (Presence or Representative) goes away, liveslots will consult the VOM to see whether it should inform the kernel about the dropped vref, or if it should wait until the VOM gives the all-clear.

Currently (#3132, #3133) the VOM is extremely conservative. If a vref has ever appeared in virtualized data, it gets marked for retention, and when liveslots asks the VOM if it is safe to do syscall.dropImports, the VOM always says "no".

The next step is to make this less conservative. The VOM should use refcounts to keep track of a vref being added as a key, or as a value, and to track when it is removed (or the containing object is deleted). When liveslots asks for permission to drop, the VOM should consult these refcounts to provide an answer.

The full state machine which the VOM needs to participate in is described in #2724 , in particular #2724 (comment) .

Basically, Presence vrefs (all o-NN object imports) are "supported" (kept alive) by either a Presence (which makes the vref both Reachable and Recognizable) or the VOM (which might make the vref Reachable or merely Recognizable). Changes in either place (the Presence being finalized, VOM data being modified, or the VOM deciding to delete a containing virtual object) must update the state machine, which might then perform a syscall.dropImport or syscall.retireImport.

Representative vrefs (all hierarchical o+N/M object exports) are supported by the kernel or by the VOM. When the vref is dropped (i.e. if the kernel signals dispatch.dropExport and the VOM cannot reach the vref through virtualized data), the VOM can delete the virtual object, which then releases all its values, possibly triggering more GC. The deleted virtual object should then trigger a syscall.retireExport, as well as examining all WeakMaps and virtual weak stores to find places where the vref was a key, and drop their related values.

The primary goal is to enable ERTP to use virtual objects for all Payments and Purses. These two kinds of objects have a limited set of behavior (the reference graph they participate in does not include cycles), so hopefully we can fully collect them with no more than basic refcounting, and won't need to implement a full mark-and-sweep garbage collector at this stage. We should implement the minimal set of features necessary to make these work, and file a new ticket for the remaining functionality.

Payments are tracked in a WeakMap for authenticity (I believe the Payment is the key, and the value is an Amount, which references a Brand object and some numbers). Purses are Remotables that close over a currentBalance and a Notifier. If both are virtual objects, each Payment will keep the Brand reachable, and each Purse will keep a Notifier reachable (and we might want to figure out how to make Notifiers into virtual objects, which might be complicated by the Promises they reference).

Description of the Design

@FUDCo is driving this, so I'm not sure what the full design should be, but I expect the VOM will need to track a reachable/recognizable count for each vref-related object. These are split into three categories (Presence, Remotable, and Representative). VOM operations will affect the refcounts, e.g. when a virtual object's property is changed, the setter should compare the vrefs in the old value against the vrefs of the newly-serialized value, and increment/decrement both the reachable and recognizable refcounts appropriately. Adding a new entry to a WeakMap should increase the recognizable refcount of the key, etc.

The VOM and liveslots must cooperate to perform drop/retire actions at the right time. I drew up the state machines with the idea that these two components were fairly separate, but they might be simpler if liveslots is merely an additional source of refcounts. Liveslots owns the WeakRefs and FinalizationRegistries that track Presence/Remotable/Representatives, and maybe it should tell the VOM when e.g. a Presence is finalized (decref by one), and let the VOM decide when the vref is thus dropped. Or maybe we should split this code out into a "reachability manager" (RM) and have it own the state machine, with both LS and the VOM reporting into it, and the RM making the syscalls, etc.

Consensus Considerations

When liveslots performs GC processing, it will be executing different code paths depending upon whether GC ran or not. We'd like to exclude this behavior from metering (so metering is not sensitive to GC timing), which we'll accomplish by turning off metering when entering the GC processing function, and turning it back on again later. So any code path that could be influenced by GC activity must remain firmly within this "meter-disabling box", which will influence the VOM design (and probably prohibits the idea of liveslots using a refcount to account for the Presence's support of the vref, if that refcount is stored in the vatStore).

Test Plan

Extensive unit tests.