On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg <[email protected]> wrote:
> In summary, there are two basic use cases for 'relations': > - permanent (key outlives object) > - temporary (object outlives key) It took me a little digging, but I found an old proposal and the -- in retrospect unfortunate -- reasons for its rejection: At < http://wiki.ecmascript.org/doku.php?id=strawman:weak_references&rev=1251679346>, the original EphemeronTable constructor included an optional opt_useKeyLifetime flag. "The opt_useKeyLifetime and opt_expectedSize parameters have no semantics but provide valuable advice to an implementation. When the underlying platform does not support accurate ephemeron collection, if the opt_useKeyLifetime flag is truthy, that suggests that the lifetime of the value should be more tied to the lifetime of the key. If opt_useKeyLifetime is falsy or absent, then the lifetime of the value should be more tied to the lifetime of the table." The argument against, which was persuasive at the time, is at: < http://wiki.ecmascript.org/doku.php?id=strawman:allen_wirfs-brock_s_comments_on_ephemeron_table_proposal >: "2) I would drop the whole opt_useKeyLifetime business [...]. The basic problems with this sort of exposed tweak is the conceptual complexity burden it creates for user. Whether they need to really know about it or not, they will worry about trying to understand it, just because it is there. And unfortunately, in most cases they won’t understand it, but since it is there they will think that it is something important and will guess at the value they should specify or just copy some other usage. Understandability of the EphemeronTable proposal is just a whole lot better if this concept is dropped. [...]" The two settings of the opt_useKeyLifetime flag correspond exactly to your two use cases. The assumption at the time is that implementations would do a good enough job at this optimization issue without this hint from the user -- which is the conversation we're now having. Had we kept opt_useKeyLifetime, we would not be having this discussion. However, we didn't, so need to find a solution starting from where we are. > 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. 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? > > but without breaking membrane transparency. > > I'm still not sure I understand how this affects membranes > specifically. What Tom said. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
