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 <[email protected]> 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 <[email protected]>: > >> 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, 현우박 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
