Proposal: Abstract References

Mark S. Miller erights at
Mon Oct 27 09:45:01 PDT 2014

On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg <rossberg at>

> 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 <>,
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: <

"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 <erights at> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list