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. > > 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
