Suggest WeakMap.prototype.values()

[Jordan Harband]

It allows an additional strong reference to `bar` to be created without
previously having a reference to `foo` - a critical security property of
WeakMaps is that without a reference to the key, you *can not ever
possibly* get a reference to the value.

In addition, it is intentional that you can not ever know if something has
been GC'd - that knowledge is not something you can obtain in JS.

On Fri, Aug 26, 2016 at 12:19 AM, Park Hyeonu <nemo1275 at gmail.com> wrote:

> 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/20bde377/attachment.html>