Hacker News Reader

Comment by stevedekorte | Hacker News Reader

Neat idea. Would moving the dependents list to an instance variable holding a weak array avoid the need for ephemerons here?

View on HN

Where would the weak array be stored? Ephemerons are often used when you can't attach data directly to either the key object or the value object. It's the simplest efficient primitive that lets you encode "if object A is reachable, object B also is" without otherwise affecting the visibility of A (or B), altering A, or needing multiple GC cycles to settle.

On the instance. My understanding is that in this example, the instance itself is the key and is only stored in a dictionary owned by the related class. Maybe there are other or broader use cases, but for this particular case, storing dependents on the instance seems to (AFAICS) solve the problem without adding complexity.

Agreed. If the dictionary is owned by the related class, and classes aren't collected themselves, then there's no point in using an ephemeron table. From a GC perspective, an ephemeron table entry can be seen as a tuple <M, K, V> where V is alive if both M and K are alive. Sort of a strong edge to V from the conjunction of M and K. (A regular strong edge is a tuple <K, V> where V is alive if K is alive.) So if the ephemeron table M is known to be alive, then it collapses down to a regular strong edge, the simplest forms of which are plain properties or dictionaries mapping Ks to Vs.

I have to admit, given the obviousness of that solution, I decided that they must have some constraint we don't know preventing it. I don't know why they didn't use it here. The broader design and use-cases have been better described by sfink in these threads.

Except that the implementation described in the post does use multiple GC cycles to settle if I read it correctly. It will only be an issue if you have reference cycles through ephemeron edges, though, like a key associated with a value that is itself or refers to an otherwise-dead WeakMap which contains a key associated with... etc.

Multiple cycles are not fundamental to ephemeron collection, though. If you keep all of your unmarked keys (specifically, keys of ephemeron tables that have been marked) in a lookup table, then in theory every time you mark anything you could look it up in that table to see if you need to traverse an ephemeron edge. In practice, you probably don't want to do those lookups until you've traversed the "easy" part of the heap that doesn't require traversing ephemerons to get to.

Source: that's how I implemented it in SpiderMonkey: https://searchfox.org/mozilla-central/rev/552bfc6334b797d92f...

Reply on news.ycombinator.com