On 27 October 2014 17:45, Mark S. Miller <[email protected]> wrote: > On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg <[email protected]> > wrote: >> > On Wed, Oct 22, 2014 at 2:26 PM, Mark Miller <[email protected]> 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. >> >> How would that generally be "known" up-front, though? Even if you were >> allowed to dynamically analyse the whole heap and code, you couldn't >> easily predict relative life times. > > Good question. First, our common assumption: > > An object layout would need to (expensively) change when > a. The object is a key in a WeakMap > b. Ephemeron collection happens > c. At the moment of ephemeron collection, the object is not deemed > garbage but the WeakMap is > > The counter-question is: > > To avoid this expense for a given WeakMap and its keys, is it adequate to > avoid the above from actually occurring, or would an implementation also > need to accurately predict that it will not occur. Put another way, if we > don't know ahead of time that the above will not occur, how cheap can we > make the case when it does not actually occur? > > If the answer is "cheap enough" and it is easy enough to make it cheap > enough, then my proposal stands.
I don't see what you could do if you couldn't predict it ahead of time. But I'm afraid the more fundamental question is: Is it adequate that this case can occur _at all_? To be honest, I don't think it is. It's not even close to "cheap enough" in terms of implementation complexity budget. > Otherwise, we need to somehow recover the functionality we lost when we gave > up the opt_useKeyLifetime flag. Given where we are, I propose another pair > of weak-map & weak-set collections, with exactly the same contract as the > current ones, except: > > * The new weak collections would have no .clear method. > * The hidden fields generated on the keys by the new weak collections would > be expected to have their full key's lifetime, whether on not the key > outlives the weak collection. > > If adding a new pair of weak collections is too expensive/ugly, is there > somewhere in our existing WeakMap/WeakSet API where we can find room to > restore the opt_useKeyLifetime flag or its equivalent? Although not pretty, I would probably be fine with that, but I still feel like it is inferior to real private properties. Mostly in terms of ergonomics and in terms (misleading) performance expectations it might set (programmers assuming a "map" should not affect the objects themselves). There are more implementation problems with transposed representations, btw: Proxies currently have no ability for storing properties, but they'd need to have that to store transposed properties. Similarly, it affects all other objects with a specialised representation (e.g. typed objects?). Transposition might also prevent certain optimisations on otherwise immutable objects, because their representation might still be mutated in non-trivial ways. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
