orphaned objects are not fully GCed: one refcount key is left in the DB

[warner]

Describe the bug

#3377 was about a kernel crash that occurred when an orphaned object was processed by processRefcounts(). The fix avoids the crash, but fails to clean up after the object fully. It leaves the ${kref}.refCount DB key in place. Normally that would be deleted when a retireExport GC action was sent to the exporter, but of course orphaned objects have no exporter. By not pushing a retireExport GC action for the late owner vat, we also fail to delete the .refCount key.

I'm not sure of the cleanest solution yet. Maybe have a special kind of "no target vat" retireExport GC action, which deletes the key but doesn't tell any vat about it? Maybe processRefcounts() should notice 1: recognizable=0 and 2: ownerVatID === undefined and delete the key itself, instead of pushing a GC action (but would the DB key change appear in the right commit window?).

The consequence is that we leave one DB key (${kref}.refCount = 0,0) around for each orphaned export of any dead vat. We don't kill vats very frequently yet (well, ok, not intentionally), so this is low-priority.

[warner]

I'm leaning towards the latter fix (have processRefcounts() do the deleting immediately.

[warner]

Might be associated with (or fixed at the same time as) #3439

[warner]

I was working on test-gc-kernel.js > terminated vat today, and noticed this clause at the bottom:

agoric-sdk/packages/SwingSet/test/test-gc-kernel.js

Lines 1168 to 1170 in bef63e5

	// TODO: we still fail to clean up the [0,0] kref: #3378 is about finding
	// somewhere to delete the .refcount key
	// t.is(refcounts[doomedExport2Kref], undefined);

which is commented out because of this bug. I uncommented that part, and it passes. Looking at the code more closely, I think it's been fixed:

agoric-sdk/packages/SwingSet/src/kernel/state/kernelKeeper.js

Lines 1276 to 1280 in bef63e5

	} else if (recognizable === 0) {
	// unreachable, unrecognizable, orphaned: delete the
	// empty refcount here, since we can't send a GC
	// action without an ownerVatID
	deleteKernelObject(kref);

That code is run when processRefcounts looks at an object with no owner, reachable === 0, and recognizable === 0, and deletes it. We added this code as part of PR #4957, to fix #4951 (add syscall.abandonExport, for liveslots to call during stopVat() back when we did that pre-upgrade), about a year after this ticket was created.

I'll make a PR that uncomments the test clause.