Removal of WeakMap/WeakSet clear

Katelyn Gadd kg at luminance.org
Wed Dec 3 14:39:04 PST 2014


Related to Andreas's points, if performance is a real concern here,
the dramatically inferior memory locality of a transposed weak map is
probably something that is at least worth thinking about. Cache
locality matters a lot in modern software, especially if you have a
large heap, and it will impact the performance of both normal
execution and collections.

There are so many moving parts involved in implementing this container
that it seems ill-advised to try and understand its overall
performance just by looking narrowly at one specific aspect like
whether or not reclaiming happens in a minor collection. In most
real-world applications, you will see containers get used in many
ways: write-once-read-many, write-many-read-once,
write-many-read-many, etc. Immutable lookup tables, mutable
short-lived state trackers for in-progress tasks, state associated
with live 'entities' or other objects, etc. If the goal here is really
to deliver the best possible performance, intuition & experience from
implementing WMs in (for example) v8 should in most cases trump the
theoretical performance of the algorithm.

Likewise, if performance is important, clearing is a common use case.
There are certainly use cases where you don't want to clear, or don't
need to, and in those cases it has been pointed out that the necessary
infrastructure to clear MIGHT slow them down. But you want to optimize
globally, where possible, so that the vast majority of use cases
perform acceptably (no horrible, unusably slow cases) while trying to
make as many of those cases fast as you can. So entirely ruling out
clear() in order to optimize one case is potentially unwise there too.

On 3 December 2014 at 06:35, Andreas Rossberg <rossberg at google.com> wrote:
> On 2 December 2014 at 19:15, Mark S. Miller <erights at google.com> wrote:
>>> In both minor or major collection both m and v are immediately
>>> reclaimed, because neither is strongly reachable at that point
>>
>> which shows the asymmetry, and that v8 is effectively optimizing for
>> the wrong side of that asymmetry. By adopting what Allen and I refer
>> to as the transposed representation (as opposed to your transposed
>> representation), you'd instead be able to say of the common scenario
>>
>>> In both minor or major collection both k and v are immediately
>>> reclaimed, because neither is strongly reachable at that point
>>
>> which would be much more valuable than any other efficiency issue
>> discussed in this thread.
>
> What I'm saying is that this is a theoretical conclusion at which you
> arrive only under various simplifying and idealistic assumptions (such
> as life time being the only factor that matters). I maintain that
> there is no evidence yet that this actually translates to better
> overall performance in practice, and I have severe doubts that it
> would. I don’t want to reiterate the concerns that I already raised in
> an earlier thread, but the executive summary is:
>
> Good performance absolutely wants an object layout that is stable and
> compact. The transposed weak map implementation pretty much is an
> antithesis to that. It hence induces a potential cost on all key
> objects (and all their uses throughout a program) instead of just the
> maps. That is a case of optimising for the wrong thing as well.
>
> (Back to the actual topic of this thread, you still owe me a reply
> regarding why .clear is bad for security. ;) )
>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list