On 27 October 2014 17:45, Mark S. Miller <erights at google.com> wrote:
> On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
>> > 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.
>>
>> 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

On 27 October 2014 17:45, Mark S. Miller <erights at google.com> wrote:

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