collect GC cycles in virtualized data

[warner]

What is the Problem Being Solved?

The virtual object manager (VOM), actually virtualReferenceManager.js, uses plain reference counting to perform GC. We don't have a mark-and-sweep collector, so we cannot yet discover and prune cycles that exist purely between virtual objects/collections. These cycles won't consume RAM, but they will consume disk space.

Currently we recommend that authors of virtual objects should perform manual cycle-breaking when those objects have an obvious "end of life" signal. Payments, for example, are single-use: once they've been deposit()ed, they have zero value and cannot be deposited again. That's a great time to delete whatever cross-links it has, which allows refcounting to collect the pieces.

Purses, however, are 1:1 with DepositFacets, and both internally reference the other. Lots of code uses short-lived Purses (escrow for a single contract invocation), but there's no self-destruct mechanism or method, so there's no great opportunity to break these object graph edges and allow a refcount to reach zero.

Description of the Design

Not sure yet. Mark-and-sweep is pretty straightforward, but we're concerned about the expense, and the timing. We probably wouldn't meter this, but it would be unfortunate if a contract were terminated because the hard xsnap computron limit was reached by the GC effort.

2870 backpointers might help.

Security Considerations

need to make sure userspace cannot sense GC

need to make sure userspace doesn't get killed by computron limits

Test Plan

careful unit tests

[erights]

Noting that many cycles are likely like purse/depositFacet, where the cycle is within a set of facets which are allocated together. #3834 will likely avoid storing cycles for these, avoid that particular case of the problem. But, of course, others remain. We don't yet know how common they are.