Questioning WeakMap.prototype.clear (was: Private symbols as WeakMap sugar)

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jan 21 11:43:27 PST 2013


On Jan 21, 2013, at 10:46 AM, Mark S. Miller wrote:

> On Mon, Jan 21, 2013 at 10:40 AM, Mark S. Miller <erights at google.com> wrote:
>> On Mon, Jan 21, 2013 at 9:02 AM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>>> If you don't want to expose clear on a WeakMap, create a subclass that doesn't support it:
>>> 
>>> class WeakMapWithoutClear extends WeakMap {
>>>   delete() {throw Error("Clearing this map is not allowed");
>>> }
>> 
>> Did you mean "clear()" rather than "delete()" ? Assuming so, how does
>> this defend against
> 
> 
> The above fragment was a leftover from a partial edit, sorry. I had
> written your clear.call attack before seeing that you'd already
> covered that below and suggested the wrapping defense.
> 
>> 
>> 
>>> 
>>> clear is an operation that can not be otherwise synthesized for WeakMaps.
>> 
>> See counter example above.

No, you ES level code does not have the immediately effect of freeing up GC resources that are associated with maintain the WeakMap. Also, not tht in a generation collection there may be a very long time interval before the discard WeakMap is recognized as such.

You can not synthesize the implementation level memory management optimizations that are possible using a built-in clear method.
>> 
>>> Given the ambient impact of the mere existance of WeakMap entries on garbage collection algorithms, it seems likely that  will be performance advantages in some situations to proactively clear a WeakMap rather than waiting for the GC to do so.  Having clear enables this while it doesn't prevent using WeakMaps in ways that don't expose that operation to ambient use.
>> 
>> This argument is backwards. It is the presence of .clear that prevents
>> the non-ephemeron optimization for the common rights-amplification
>> pattern.

I'm actually primarily interested in uses of WeakMap where ephemeron behavior is necessarly -- representing external relationships between arbitrary objects. 

Allen




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130121/d192c400/attachment.html>


More information about the es-discuss mailing list