On Mon Jul 17 15:18:53 2023 +0000, Jacek Caban wrote:
BTW, what's the best way to track weak refs here? Let's say we have a
rb_tree that maps an object to such tracking. We'd need a list of WeakMaps and possibly the entry values (associated with the key) for the "value" of the rb_tree. An array, like props, that doubles in size everytime it exceeds its max? Or something else? It could probably be just a list of map entries. Eg. instead of `weakmap_entry`, you could have:
struct weak_reference { struct rb_entry map_entry; struct list key_entry; jsdisp_t *key; jsval_t value; int gc_mark; };It would be both part of mentioned list associated with jsdisp_t and WeakMap.
There could be cyclic refs in the entry value's path. If we unconditionally visit them from both the key and the WeakMap, they will be marked alive when either of them is alive, not when *both* of them are. For example if we keep the WeakMap alive (local variable for example), the entries will also remain alive, even if the key is released.
Traversing basically unmarks the entire path from garbage collection; only one traversal is enough to do this, it's an "OR" operation, not an "AND". That's why we need to add those conditions I mentioned.