d at domenic.me (2014-11-18T22:59:48.001Z)
On Fri, Oct 24, 2014 at 4:19 AM, Andreas Rossberg <rossberg at google.com> wrote: > I appreciate your analysis, but I respectfully disagree with your > conclusion. > > - The extra slot and indirection for the [[Shadow]] property is an > extra cost (V8 already has a very similar mechanism to implement > "hidden properties" as provided by its API (and in fact, hash codes), > but it is known to be (too) slow). > > - Optimising away this slot is difficult -- for starters, because it > will have various secondary effects (e.g., every add/remove of an > object to/from a weak map will potentially result in a layout change > for that object, increasing spurious polymorphism, and potentially > invalidating/deoptimising existing code). > > - Worse, when you flatten weak properties into objects, then even GC > could cause object layouts to change, which is a whole new dimension > of complexity. > Already answered: On Wed, Oct 22, 2014 at 2:26 PM, Mark Miller <erights at gmail.com> wrote: > [...] When the WeakMap is known to necessarily live longer than its keys, > as for class-private state, then those shadow properties can even be > exempted from the [ephemeron] key-mark-check. > More to the point, when the instance (transientKey) retains the WeakMap (via instance retains class retains methods retains field designators), then GC will never cause this layout change. Caveat: If the field (WeakMap) objects in question are available to user code, then they might be .clear()ed, in which case GC would indeed cause this layout change. This is one of many reasons why I still think .clear() should not be provided by WeakMap and WeakSet. The inclusion of Weak* .clear() never achieved consensus, so I believe it violates our process for these to be included in the spec. > - On the other hand, if you do _not_ do this flattening, performance > is unlikely to ever be competitive with true private properties (we > internally introduced private symbols in V8, exactly because the extra > indirection for hidden properties was too costly). > Exactly. For WeakMaps representing private state, they should engage exactly the kind of runtime machinery once associated with private symbols, but without breaking membrane transparency.
On Fri, Oct 24, 2014 at 4:19 AM, Andreas Rossberg <rossberg at google.com> wrote: > On 22 October 2014 16:45, Mark S. Miller <erights at google.com> wrote: > > On Tue, Oct 21, 2014 at 11:59 PM, Andreas Rossberg <rossberg at google.com> > > wrote: > >> > >> On 21 October 2014 22:31, Mark S. Miller <erights at google.com> wrote: > >> >> in saying that [weak maps] are not designed to work efficiently in > that > >> >> manner. > >> > > >> > Actually, they are. The problem is that initial implementations date > >> > from > >> > before we appreciated the need for the transposed representation. The > >> > best > >> > thing TC39 can do for the future of WeakMaps is to proceed assuming > the > >> > transposed representation. > >> > >> While I sympathise, let me clarify that this still remains a > >> conjecture. AFAIK, nobody has proved it empirically in a JS > >> implementation yet, we don't know in detail how complex such an > >> implementation would be, and what side effects it might have on > >> general performance (e.g., via added polymorphism). It's most likely > >> not as easy or as clear a win as you may think it is. > > > > > > The following code is an existence proof of sorts that, given only the > > WeakMap mechanisms you've already built + one bit of magic whose > feasibility > > I hope we don't need to debate. I use ES5 here to make clear that no > other > > magic or unengineered features are assumed. > > > > > > var WeakMap; > > > > (function() { > > 'use strict'; > > > > var SlowWeakMap = WeakMap; > > > > function FastWeakMap() { > > var token = Object.freeze(Object.create(null)); > > return Object.freeze({ > > get: function(key) { > > var shadow = key.[[Shadow]]; > > return shadow ? shadow.get(token) : void 0; > > }, > > set: function(key, value) { > > var shadow = key.[[Transposer]] > > if (!shadow) { > > shadow = new SlowWeakMap(); > > key.[[Transposer]] = shadow; > > } > > shadow.set(token, value); > > }, > > clear: function() { > > token = Object.freeze(Object.create({})); > > } > > }); > > } > > > > // Don't do this until it is a complete shim > > // WeakMap = FastWeakMap; > > > > }()); > > > > > > > > The magic is that each object, whether frozen or not, would need in > effect > > one extra internal mutable [[Shadow]] property. > > > > Clearly, this expository implementation is suboptimal in many ways. But > it > > demonstrates the following: > > > > * It provides the full complexity measure gains that a realistic > > implementation would have. > > > > * For each of these objects, an extra SlowWeakMap instance is allocated > as > > its shadow. > > > > * For each access, an extra indirection through this SlowWeakMap is > > therefore needed. > > > > * Only objects that have been used as keys in FastWeakMaps would ever > have > > their [[Shadow]] set, so this could also be allocated on demand, given > only > > a bit saying whether it is present. Besides this storage of this bit, > there > > is no other effect or cost on any non-weakmap objects. > > > > * Since non-weakmap code doesn't need to test this bit, there is zero > > runtime cost on non-weakmap code. > > > > * Whether an object has been used as a key or not (and therefore whether > an > > extra shadow has been allocated or not), normal non-weak property lookup > on > > the object is unaffected, and pays no additional cost. > > > > A realistic implementation should seek to avoid allocating the extra > shadow > > objects. However, even if not, we are much better off with the above > scheme > > than we are with the current slow WeakMap. > > > > Of course, we should proceed towards realistic implementations asap and > get > > actual empirical data. But the above demonstration establishes that the > > issue in this thread should be considered settled. > > I appreciate your analysis, but I respectfully disagree with your > conclusion. > > - The extra slot and indirection for the [[Shadow]] property is an > extra cost (V8 already has a very similar mechanism to implement > "hidden properties" as provided by its API (and in fact, hash codes), > but it is known to be (too) slow). > > - Optimising away this slot is difficult -- for starters, because it > will have various secondary effects (e.g., every add/remove of an > object to/from a weak map will potentially result in a layout change > for that object, increasing spurious polymorphism, and potentially > invalidating/deoptimising existing code). > > - Worse, when you flatten weak properties into objects, then even GC > could cause object layouts to change, which is a whole new dimension > of complexity. > Already answered: On Wed, Oct 22, 2014 at 2:26 PM, Mark Miller <erights at gmail.com> wrote: > [...] When the WeakMap is known to necessarily live longer than its keys, > as for class-private state, then those shadow properties can even be > exempted from the [ephemeron] key-mark-check. > More to the point, when the instance (transientKey) retains the WeakMap (via instance retains class retains methods retains field designators), then GC will never cause this layout change. Caveat: If the field (WeakMap) objects in question are available to user code, then they might be .clear()ed, in which case GC would indeed cause this layout change. This is one of many reasons why I still think .clear() should not be provided by WeakMap and WeakSet. The inclusion of Weak* .clear() never achieved consensus, so I believe it violates our process for these to be included in the spec. > - On the other hand, if you do _not_ do this flattening, performance > is unlikely to ever be competitive with true private properties (we > internally introduced private symbols in V8, exactly because the extra > indirection for hidden properties was too costly). > Exactly. For WeakMaps representing private state, they should engage exactly the kind of runtime machinery once associated with private symbols, but without breaking membrane transparency. > > I'm still sceptical that we can actually resolve this dilemma, > especially when this is supposed to be a solution for private state. > It seems to me that the performance implications of weakness are > fundamentally at odds with the desire to have efficient private state. > > /Andreas > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141024/8bc86503/attachment.html>