Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(liveslots): collection deletion didn't free key objects
Fix collection deletion. Previously, objects (passables/vrefs) used as collection keys were not de-referenced when the collection was dropped/deleted or unconditionally cleared (`collection.clear()` without keyPatt or valuePatt). Strong collections would leak a reachable-refcount to the key object, and weak collections would leak a recognizable-refcount, leading to the object being kept alive (or kept unretired) forever. In addition, each entry would leak a vatstore key until the collection was finally deleted. The code in `clearInternalFull()` confused dbKeys, encodedKeys, and vrefs, and gave the wrong kind of key to `isEncodedRemotable()`, so the answer was always "no". fixes #8756 move test, new naming convention more test, needs refactor refactor test finish weak-collection test fix: retire objects from weakstore recognizers add test of voAwareWeakSet deletion and retirement simplify add/removeRecognizableVref These functions have two purposes: * track "recognition records" for keys of weak collections * tell BOYD about Presence vrefs (addToPossiblyRetiredSet) when a record is removed Virtual/durable weak stores keep their recognition records in vatstore `vom.ir.${vref}|${collectionID}` keys. voAwareWeakMap/Set keeps them in RAM, in a Map named vrefRecognizers, where the key is the vref being recognized, and the value is a Set of virtualObjectMaps (one per recognizing WeakMap/Set). Adding a record means adding a `vom.ir.` key, or adding to the Set (which might require adding a Map entry). Removing a record means removing a `vom.ir.` key, or removing from the Set (and maybe the Map entry). We need to add the vref to possiblyRetiredSet when both 1: it is a Presence-style vref (o-NN), and 2: it might be the last recognizer. For `vom.ir.` keys, we do this for every Presence-style vref, whether or not we're the last one, because searching for other records would be expensive. For voAwareWeakMap/Set, we have to delete the Map entry if the Set became empty anyways, so we only addToPossiblyRetiredSet if it was the last one. The previous version only updated records for Presence-style and Representative-style (virtual/durable object) vrefs, and avoided updating records for Remotable-style vrefs. This changes the logic to update records for all vrefs, so that retiring a key can remove the weakstore entry (and its associated data, for WeakMapStores). This causes two behavioral changes: * add vom.ir. keys for Remotable vrefs * only addToPossiblyRetiredSet for presence-style vrefs in weakstores make virtualReferences right more more more
- Loading branch information