Questioning WeakMap.prototype.clear

Mark S. Miller erights at google.com
Mon Jan 21 13:55:18 PST 2013


On Mon, Jan 21, 2013 at 1:42 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> 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.

That's why it's important that common patterns, such as the rights
amplification pattern, which don't actually need the costs of
ephemeron gc, shouldn't have to pay these costs because of the
presence of a clear method they don't use.


>
>>
>> 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?
>
> Allen
>
>
>
>
>
>
>
>>
>> David
>>
>> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-January/028370.html
>> [2] https://mail.mozilla.org/pipermail/es-discuss/2013-January/028371.html
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list