Thoughts on WeakMaps
mikesamuel at gmail.com
Mon Jun 6 14:41:07 PDT 2011
2011/6/6 David Bruant <david.bruant at labri.fr>:
> 2) The notion of weak reference as used in current WeakMap seems to be
> assuming that the garbage collector will work on whether objects are
> reachable or not. I have read (I thought it was the wikipedia page, but it
> apparently wasn't) that there is another notion for garbage collection which
> is whether an object will be used or not in the future. Of course, this
I don't know what you read, but there's one way of thinking about GC
is that an ideal garbage collector would collects all objects that
will not be used. All real garbage collectors have to conservatively
approximate that ideal.
This is similar to thinking about LRU and similar cache algorithms as
approximating (non conservatively) the next n to be requested.
> notion is far more difficult to determine than reachability, but this is not
> my point.
> Let imagine for a minute that a lot of improvements is done in the field of
> object non-future-use. Will WeakMap be any different than a regular Map?
> If an engine is able to tell that an object will not be reachable, does it
> matter if there are remaining (soft or strong) references?
> 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.
More information about the es-discuss