Use cases for WeakMap

Oliver Hunt oliver at apple.com
Mon May 16 11:37:50 PDT 2011


On May 16, 2011, at 11:30 AM, Erik Corry wrote:

> 2011/5/16 Andreas Gal <gal at mozilla.com>:
>> 
>> Even if you want to store weak-map specific meta data per object, nobody would store that directly in the object. Thats needlessly cruel on the cache since >>99.9% of objects never end up in a weak map. Instead one would locate that meta data outside the object in a direct mapped dense area (like mark bitmaps), which is on its own page that is not write protected.
> 
> More than 99.9% of objects don't have a property called "fish".
> Nevertheless if someone adds a "fish" property to an object V8 will
> try to (and usually succeed in) storing it in the object and it won't
> be cruel on the cache.  Quite the opposite.

I agree.

The same logic applies to object hashcodes -- an object must always produce the same hashcode which means it will need to store it -- having a secondary map doesn't help you, because that map will itself require a hascode.  However making every object always have space to store a hashcode is wasteful of memory, so essentially some form of "private name" must be used.  I think i saw someone (Erik?) say that this is what v8 does.

--Oliver

> 
>> 
>> Andreas
>> 
>> On May 16, 2011, at 10:39 AM, Brendan Eich wrote:
>> 
>>> 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?
>>> 
>>> http://hg.mozilla.org/tracemonkey/rev/7dcd0d16cc08
>>> 
>>> 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.
>>> 
>>> /be
>> 
>> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list