Please do nitpick. I wrote this in too much of a hurry and it is something
that needs care.

In any case, yes, transientKey.

On Wed, Oct 22, 2014 at 2:46 PM, Rick Waldron <waldron.rick at gmail.com>
wrote:

>
>
> On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller <erights at gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink <sphink at gmail.com> wrote:
>>
>>> On 10/22/2014 07:45 AM, Mark S. Miller wrote:
>>> >
>>> > * Only objects that have been used as keys in FastWeakMaps would ever
>>> > have their [[Shadow]] set, so this could also be allocated on demand,
>>> > given only a bit saying whether it is present. Besides this storage of
>>> > this bit, there is no other effect or cost on any non-weakmap objects.
>>> >
>>> > * Since non-weakmap code doesn't need to test this bit, there is zero
>>> > runtime cost on non-weakmap code.
>>> >
>>> > * Whether an object has been used as a key or not (and therefore
>>> > whether an extra shadow has been allocated or not), normal non-weak
>>> > property lookup on the object is unaffected, and pays no additional
>>> cost.
>>>
>>> Maybe it's because I work on a garbage collector, but I always think of
>>> the primary cost of WeakMaps as being the GC. The above analysis doesn't
>>> take GC into account.
>>>
>>
>> I should have been more explicit, but GC costs are almost my entire
>> point. These costs aside, my FastWeakMaps are more expensive in all ways
>> than SlowWeakMaps, though only by a constant factor, since each FastWeakMap
>> operation must also perform the corresponding SlowWeakMap operation.
>>
>>
>>
>>>
>>> In the straightforward iterative implementation, you record all of the
>>> live WeakMaps found while scanning through the heap. Then you go through
>>> them, checking each key to see if it is live. For each such key, you
>>> recursively mark the value. This marking can discover new live WeakMaps,
>>> so you iterate to a fixed point.
>>>
>>
>> That is when you find yourself doing an ephemeron collection. The point
>> of the transposed representation is to collect most ephemeron garbage using
>> conventional collection. Consider
>>
>> var fastField = new FastWeakMap();
>> var slowField = new SlowWeakMap();
>>
>> var transientKey = {};
>>
>> var fastValue = {};
>> var slowValue = {};
>>
>> fastField.set(key, fastValue);
>> slowField.set(key, slowValue);
>>
>
> I don't mean to nit-pick, but "key" is "transientKey", right?
>
> Rick
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141022/971be457/attachment.html>

Please do nitpick. I wrote this in too much of a hurry and it is something
that needs care.

In any case, yes, transientKey.