Suggest WeakMap.prototype.values()

[Park Hyeonu]

Well the entry in the WeakMap has strong reference of it's value, so the
value never GCed until it's key is GCed even in the case all other
references are gone. Say, we have a WeakMap [foo -> bar], then the object
bar will never GCed until foo is GCed. So allowing access to the `values`
of the map do not make additional strong reference.

And for my use case, what I want is to check whether the object is GCed or
not. To supplement my previous explanation, what i originally attempt to do
was make an WeakMap<DataNode -> NodeId> in each worker context and when
some Id is confirmed to gone, clear the corresponding memory space on
SharedArrayBuffer. So in this case Map cannot be an alternative, as every
keys in Map is guaranteed not to GCed.

But I have no idea why you suggest multiple WeakMaps. Could you explain it
more please?

2016-08-26 16:02 GMT+09:00 Jordan Harband <ljharb at gmail.com>:

> The whole point of a WeakMap is that without a strong reference to the
> key, you can't have a strong reference to the value. A `values()` iterator
> would give you a strong reference to the value without you needing to have
> a strong reference to the key.
>
> If that's your use case, use a `Map`, or use multiple `WeakMap`s.
>
> On Thu, Aug 25, 2016 at 10:55 PM, 현우박 <nemo1275 at gmail.com> wrote:
>
>> I know it's the design choice that WeakSet and WeakMap's key is not
>> enumurable because it's weak, but I think values in WeakMap is little
>> different.
>>
>> WeakSet's values and WeakMap's keys must not be referenced from the
>> map/set itself. If values from WeakSet can be accessed, then it cannot be
>> GCed. And it's not we want for WeakMap/Set.
>>
>> But well, WeakMap's values ARE referenced from WeakMap, via map.get(key).
>> So values in WeakMap cannot GCed until it's matching key is GCed, and it's
>> intended feature.
>>
>> My suggestion is, a new WeakMap method that does same thing as
>> Map.prototype.values(). With such method, we can utilize JS runtime's GC
>> functionality in userspace.
>>
>> For example, I'm planning to make immutable data structures on
>> SharedArrayBuffer to boost data passing speed between Workers. As you may
>> know proper GC is the important problem for immutable data structure. But
>> in this case GC is not the free lunch as data is shared between multiple JS
>> context. So I need to check manually what data node is still visible in
>> each context, and clear unused data manually.
>>
>> Please tell me your idea about this suggestion
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160826/d4750d7c/attachment-0001.html>