more comment updates

packages/swingset-liveslots/src/boyd-gc.js

@@ -151,12 +151,19 @@ import { parseVatSlot } from './parseVatSlots.js';
   getValForSlot would allow such COLLECTED vrefs to be retired, even
   before the finalizer had fired and could do a dropImports.
 
-  Deleting a virtual object will delete its `state`, decrementing the
-  refcounts of any objects therein, which might shake loose more
-  data. So we keep looping until we've stopped adding things to
-  possiblyDeadSet. Retiring a Presence-style vref, on the other hand,
-  cannot shake anthing loose. So we do not include the
-  possiblyRetiredSet processing inside that loop.
+  When we decide to delete a virtual object, we will delete its
+  `state`, decrementing the refcounts of any objects therein, which
+  might shake loose more data. So we keep looping until we've stopped
+  adding things to possiblyDeadSet. The same can happen when we use
+  vrm.ceaseRecognition() to delete any weak collection values keyed by
+  it. We also call ceaseRecognition when we realize that a Remotable
+  has been deleted. But the possiblyDeadSet processing loop cannot
+  make the decision to retire a Presence-style vref: those are deleted
+  outside our vat, and the kernel notifies us of the vref's retirement
+  with dispatch.retireImports (which also calls ceaseRecognition). The
+  only thing possiblyDeadSet can tell us about Presences is that our
+  vat can no longer *reach* the vref, which means we need to do a
+  syscall.dropImports, which cannot immediately release more data.
 
   When the kernel sends us a dispatch.bringOutYourDead (or "BOYD" for
   short), this scanForDeadObjects() will be called. This is the only