On May 16, 2011, at 11:37 AM, Oliver Hunt wrote: > On May 16, 2011, at 11:30 AM, Erik Corry wrote: > >> 2011/5/16 Andreas Gal <[email protected]>: >>> >>> 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.
SpiderMonkey has "reserved slots". But this is all beside the point. Frozen objects are not observably extensible. I argued that we want an implementation option to put their shallowly-frozen state (values at least) in read-only memory. I have not seen anything like an argument why this option should be forbidden. /be > > --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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
