Questioning WeakMap.prototype.clear

Allen Wirfs-Brock allen at
Mon Jan 21 13:42:59 PST 2013

On Jan 21, 2013, at 12:25 PM, David Bruant wrote:

> Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
>> On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
>>> This is the reality check I can get behind—I'm hard pressed to come up with a use case that isn't contrived or solvable by some other means.
>> This is easy:
>> I'm do phased traversals over a complex data structure.  I have a number of functions that collaborative perform the function and they share access to a WeakMap to cache relationships that they identify over the course of the traversal.  When I start a new traversal phase I want to flush the cache so I use the clear method to do so.
> Creating a new weakmap would work equally well to flush the cache.

Same arguments applies to Map clear.  I'm actually more comfortable with a discussion of the utility of the clear method for maps, in general.  But, if it has utility for Map then it has the same utility for WeakMap and supplying on both is a matter of API consistency.

> Note that the current WeakMap.prototype.clear method is specified as:
> "Set the value of M’s [[WeakMapData]] internal data property to a new empty List." which is quite close from creating a new weakmap.

No it is very different.  The fact that we are talking about a "List" (ie, not an actual observable object) and an internal data property means that an implementation is able to aggressively manage those resources in ways that is not possible  with a vanilla reference to a observable object that may have other references

> If you care about reusing the same object, Mark's encapsulation [1]+[2] works too.
> I intuit perf differences can be made marginal by engines in both cases. If I were wrong on that, implementors or authors will tell.
> The Firefox precedent shows that it took ~3 weeks from the bug being filed to implementation to add .clear to an existing WeakMap implementation, so I'm not too worried about that either.

These techniques do not allow for the same implementation level optimizations.

 I don't know how many people on this list have implemented production generational GC with ephemeron support.  I have.  I'm telling been trying to tell you that weak abstractions in general and ephemerons in particular will have a systemic impact upon GC throughput. Also, generational collectors can have large latencies between the time the last reference to an object is destroyed and the when the GC actually notices.  Many GC cycles may occur during that period and if a populated but unneeded large WeakMap is one of these zombie object, then it can have perf impacts. 

> I think .clear can wait and people would need to clear can either create new weakmaps or wrap weakmaps as Mark showed.

For Map too, right?


> David
> [1]
> [2]

More information about the es-discuss mailing list