Andreas Rossberg (2014-10-27T14:00:25.000Z)
d at domenic.me (2014-11-18T23:00:17.901Z)
On 24 October 2014 22:13, Mark S. Miller <erights at google.com> wrote: > 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. 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. > 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. With everything being mutable in JavaScript, none of these retains-relations are necessarily invariant, as far as I can see. And even if they were, this would already be a very expensive check to make for every private field you add. It is a pretty limited scenario, too. It would not remove the general problem of the GC having to be able to rewrite object layouts, nor other use cases being unexpectedly slow. (VMs are already terrible at handling _explicit_ property deletion efficiently.) > Exactly. For WeakMaps representing private state, they should engage exactly > the kind of runtime machinery once associated with private symbols, Private symbols do not require weakness, however. That makes them both much cheaper and much easier to implement. In summary, there are two basic use cases for 'relations': - permanent (key outlives object) - temporary (object outlives key) These two use cases come with different performance implications. Transient properties seem suboptimal in either case: - They are less efficient than private symbols for the permanent case, even if you manage to flatten (which is complicated). - They are less efficient than normal weak maps for the temporary case, even if you do _not_ flatten (far worse if you flatten). Unless we can come up with some real clever heuristics for -- cheaply and reliably! -- distinguishing the two use cases at creation time of each relation, I expect that transient properties are going to be significantly inferior to the alternatives in terms of performance. And that is still ignoring the implementation complexity (and potential space overhead that I did not mention in my bullet list). > but without breaking membrane transparency. I'm still not sure I understand how this affects membranes specifically. A membrane would never pass a proxied object to a non-proxied function from the same side. So functions accessing (or testing for) private state on an object are a non-issue in that scenario, because this access never crosses the membrane, does it? After all, membranes work just fine with builtins or host objects (otherwise they would be useless).