On May 11, 2012, at 2:39 AM, Brandon Benvie wrote: > Yeah I modified gozala's method a bit. The value isn't kept in valueOf, > rather in a null proto object that allows different WeakMaps to not step on > another one. > > Maybe my understanding was flawed, but my understanding was that it's not an > issue for these single purpose objects/closures in terms of garbage > collection. A set of objects (mostly null proto objects that only ever have > one or no refereces to other objects, and only one reference to them from the > local system, essentially will act like one "unit" and ultimately the > livelihood of all of them maps back to the single key object that is the > entry point for them. The only other object that ever gets a reference to any > of them is the weakmap instance, which never keeps any references. It simply > has all the keys to unlock the gates to get to the mapped value when > requested. > > Would the garbage collection for this be more complex than I imagine? Or > would it be pretty easy to clearly link them in the way I supposed. If my > understanding is right, the remaining issue is the circular reference one in > terms of key -> value -> key -> value keeping each other alive. I had kind of > supposed that this itself would fall under the same rules though because it's > determinable whether that kind of set is reachable from roots or not. > > I'm also curious of what significance, if any, of the fact that the actual > organization of the data "map" isn't just weak by declaration/fiat but is > weak in the sense that the weakmap itself actually has no references to any > data at all aside from one string key and one hash key that proves identity > and can only do its job by being given references to objects and seeing if > the keys work. Perhaps this is immaterial or I may just not understand the > underlying reality of how the data is organized. > > Abstractly a weak map is just a way to identify a specific unidirectional relationship between pairs of objects (lets call them the "source" and "target"). Given a specific such relationship and a source object it should be easy to produce the target object. There are two pretty obvious ways to represent this abstraction. You can have an object (corresponding to the relationship) to which is attached a table of key/value pairs where the keys are source objects and and the values are target objects. Our you can attach to each object that is used as a source a table of key/value pairs where the keys are relationship objects and and the values are target objects.. There may be tons of specific implementation variations and details for either approach, but fundamentally that it what it comes down to.
Using normal garbage collector reachability rules, either of the approaches will be leaky. When a source/target table is used, the source objects will not get garbage collected as long as the relationship object is reachable; even when the only reference to a source object are from within such a table. When a relationship/target table is used, the relationship objects will not get GC'ed as long as one of its source objects is reachable; even when the only reference to the relationship object is from such a table. So depending upon the approach you will either leak source objects or relationship objects. In both cases, the leaky key values also lead to retention of otherwise GC'able target objects. The only way around this is for the GC to know about such tables and to treat them specially. The "Weak" in the name of the abstraction is simply an indication of the requirement for this special treatment. Arguably "NonLeakyMap" would be an even more describe name. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
