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

> On Mon, Jan 21, 2013 at 10:40 AM, Mark S. Miller <erig...@google.com> wrote:
>> On Mon, Jan 21, 2013 at 9:02 AM, Allen Wirfs-Brock
>> <al...@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




_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to