WeakMap.prototype.clear performance

David Bruant bruant.d at gmail.com
Tue Jan 22 14:35:58 PST 2013

Thanks a lot for these explanations! (Answer below)

Le 22/01/2013 22:46, Jason Orendorff a écrit :
>>     Having said all that, I bet we could hack around the worst-case
>>     GC performance. It'll be a pain, but GC is like that sometimes.
>     What you said above about the current GC setup that yields
>     equivalence performance to .clear is interesting. In a nutshell,
>     moving to a (naive?) generational GC means that you're losing
>     something you had before. I feel there is a middleground to be found.
> What you're losing when you switch to a generational GC is precision. 
> The tradeoff is: you do a lot less GC work, but you collect objects 
> that survive a generation much less aggressively.
>     What about the following:
>     WeakMaps are allocated in their own area which is manually GC'ed
>     with today's algorithm (which is probably implemented for the last
>     generation?). This way, you'll know as soon as possible (next GC)
>     if one is dead.
> I don't understand. How do you know if one is dead, short of marking 
> the entire heap?
I understand the problem now. An "old" object may hold a reference to a 
weakmap and you can't know until the entire heap has been marked which 
happens less often.
Specifically, in Mark's pattern, the WeakMapWithClear object outlives 
the weakmaps it encapsulates and until you've found out that this object 
is dead, the formerly encapsulated weakmap can't be declared as dead.

So, to find out if a weakmap is dead, it has to come from another source 
than the mark-and-sweep algorithm (since it losts its precision)...
Given the additional prohibitive cost weakmaps seem to have on the GC, 
maybe things that would otherwise be considered too costly could make 
sense to be applied specifically to WeakMaps. For instance, would the 
cost of reference-counting only weakmaps be worth the benefit from 
knowing early that the weakmap is dead? (I have no idea how much each 
costs, so it's hard for me to compare the costs)
For WeakMapWithClear, reference counting would declare the weakmap dead 
as soon as the new weakmap is assigned to the private property so that's 
good. It wouldn't work if some weakmaps are part of a cycle of course... 
but maybe that it's such an edge case that it's acceptable to ask users 
doing that to break their weakmaps cycle manually if they don't want the 
GC not to be too mad at them.

Thanks again for the clarifications!

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

More information about the es-discuss mailing list