On Mon Jul 17 14:30:34 2023 +0000, Jacek Caban wrote:
Do you have some ideas to tackle this problem?
What's wrong with my earlier suggestion? During GC_TRAVERSE, you could traverse weak ref entry both when traversing the object itself and the weak map. On the first visit, just mark the entry as visited. On the second visit, continue visiting the value. It means that if any of them are missing, value will not be marked as alive. All of that may happen during regular GC steps, so no extra passes are needed. And again, jsdisp_t memory overhead is avoidable.
That creates a "either key OR weakmap keeps it alive", but we want "both key AND weakmap keep it alive" situation — i.e. it will leak in some cases when the map is alive.
After all, such an entry would only be alive if both the key and the weakmap are alive, else it cannot be accessed.
Perhaps the following would work (let me know if you can figure out a wrong case):
* When traversing objects, if they have weak refs, traverse the values associated with them from the weakmap **only if** the WeakMap is alive at this point. Note that WeakMaps can become alive later down the line. * When traversing a WeakMap, check if the key is alive before traversing the associated value. If it is, traverse the value, because it means the key did not traverse it due to the WeakMap not being alive earlier, even though it actually is.
Scenarios:
If the WeakMap is traversed first, and key is not alive, the value will not get traversed, but the WeakMap will be marked alive. If the key later turns out to be alive, it will traverse the value as part of step 1, so no wrong unlinks.
If the key is traversed first, and WeakMap is not alive, the value will not get traversed during the key's traversal. If the WeakMap is later traversed and turns out to be alive, it will see the key is alive (because it got traversed), and thus traverse the value.
I think it should handle all cases?
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?