Use cases for WeakMap

Brendan Eich brendan at
Mon May 16 10:39:47 PDT 2011

On May 16, 2011, at 12:47 AM, Erik Corry wrote:

> I think the objects used as keys in weak maps need to be somehow
> annotated with this information so that the GC can clean up the weak
> maps when the keys die.  This means that if you take an object that is
> frozen and use it as a key in a weak map then it will need to be
> mutated in some way and can't be on a read-only page.

That's already false in Firefox nightlies. We support Object.freeze. We have a WeakMap implementation. We do not mutate the frozen object. Its GC metadata does not reside in a header for it, or even in the same OS page.

> Perhaps you have a different, efficient, implementation.  I can't see
> us gaining much from putting frozen objects on read-only pages, thus I
> can't accept it as a very strong argument about the way that frozen
> objects should work together with a new feature.

This is a bit too subjective an argument, sorry.

My point about 50+ years of OS and MMU firewalling is important. Chrome (recently hacked by French spook-types, but also hacked over a year ago with a two-step attack) is a convincing example.

Sure, we have user-code isolation tools in our belts, including fancy compiler/runtime pairs. But it's hard to beat processes if you want to be sure. No silver bullet, simply "stronger isolation".

>> Weak maps are in Firefox nightlies. We're playing with page protection too (not for freezing, yet). This seems like a dare, but it also seems to be dodging my point in replying again: that private names cannot be used to extend frozen objects in the "[[Extensible]] = true" sense of the spec.
> Is there a description anywhere about how you have implemented GC of weak maps?

Look for WeakMap::mark... names. There's no need to mutate a key object. There should not be, either.

Yes, this GC can iterate. A lot, but a "fix" doesn't obviously require mutating (possibly frozen) key objects. Also, since POITROAE we are going to measure twice, Optimize once.


More information about the es-discuss mailing list