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!

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

Reply via email to