Thoughts on WeakMaps

David Bruant david.bruant at labri.fr
Tue Jun 7 06:54:39 PDT 2011


Le 06/06/2011 18:30, Mark S. Miller a écrit :
>
>
> On Mon, Jun 6, 2011 at 2:46 PM, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
>
>     Le 06/06/2011 17:41, Mike Samuel a écrit :
>     > 2011/6/6 David Bruant <david.bruant at labri.fr
>     <mailto:david.bruant at labri.fr>>:
>     >> The consequence of this second point is wondering whether it's
>     a good idea
>     >> to standardize WeakMap (instead of Map) at all.
>     > Besides a lack of out-of-memory errors and performance, a program
>     > using an object key map that doesn't use ephemeron pairs shouldn't
>     > behave differently than one that does.  But developers need to have
>     > some idea of memory performance when choosing an appropriate
>     > collection.  If you're documenting, I would document the behavior
>     > around GC upon which devs can rely.
>     Not only there is a memory performance difference, but also a key
>     enumerability difference. With WeakMaps, keys cannot be enumerated
>     in a
>     determinist manner while they can with Map.
>
>
>
> This enumerability is crucial to the difference in how conservative an
> approximation to "will not be used" needs to be to be safe. If we got
> rid of WeakMap and only had enumerable Map, the GC would need to
> determine that a given map would never be enumerated in order to gc it
> as aggressively. Put another way, resource issues aside, WeakMap's
> contract is merely the non-enumerable subset of Map's contract. The GC
> knows that a WeakMap won't be enumerated because it can't be.
So maybe that the harmony:simple_maps_and_sets proposal should do the
"todo" and add the iteration (or an enumeration) method. Otherwise, the
Map proposal has no more value than the WeakMap proposal ;-)

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


More information about the es-discuss mailing list