Suggest WeakMap.prototype.values()
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 WeakMaps.
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>:
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.
For your case I would suggest deterministic scope for objects via promises and reference counting across workers. For your case you don't need to really GC object - you can just put in invalided internal state.
See sequelize transaction handling for similar solution.
However, observing GC would be great.
IMHO, it should be resolved in WeakRefs (Stage 1).
tc39/proposal-weakrefs
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