Feature-Request: allow to iterate over WeakSet / WeakMap

[Allen Wirfs-Brock]

> On Jul 13, 2016, at 9:45 AM, Michael Kriegel <michael.kriegel at actifsource.com <mailto:michael.kriegel at actifsource.com>> wrote:
> 
> Wouldn't it be preferable to discuss, whether the requested feature makes sense or not, before looking at whether it is possible to easily implement it in the current garbage collectors on the market?

But that discussion has already taken place within TC39 (and on es-discuss) during the development of WeakMap/WeakSet.

Also, this isn’t about markets, it’s about technical feasibility. Nobody knows how to implement a 0 latency, totally deterministic, low overhead GC.  It’s likely that such a thing isn't even possible given current processor/memory/software architectures. 


> 
> On 13.07.2016 18:11, Allen Wirfs-Brock wrote:
>> 
>>> On Jul 13, 2016, at 7:18 AM, Michael Kriegel <michael.kriegel at actifsource.com <mailto:michael.kriegel at actifsource.com>> wrote:
>>> 
>>> I am not sure, which kinds of garbage collectors the implementations of ECMAScript typically use. If they used a reference counter, which counts "non-weak" references only, a simple check, whether the reference count is 0 or not on access to a weak reference would be sufficient.
>> 
>> Reference counting is not “garbage collection” because reference counting can not recover circular chains of object references.
> 
> Of course not. However, reference counting can recover from circular chains. Example:

That statement simply demonstrates that you aren’t well schooled in memory management technology.  If you want to be taken seriously, please educate yourself.

> 
> imagine, deleting a hard reference internally invokes deleteReference with following implementation:
> 
> deleteReferenceTo(Obj) {
>   ReferenceCount[Obj]--;
>   if (ReferenceCount[Obj] === 0) {
>     for (Key in Object.getOwnProperties(Obj)) {
>       delete Obj[Key];
>     }
>   }
> }
> 
> delete Obj[Key] will call deleteReference. Once this delete call returns, there may be no further reference to the object Obj[Key] referred to. Then delete recursion occurs for that object. If there is a circle of objects without any further hard references to, the recursion will end, as the properties of the objects are deleted immediately. But as the object has no references to it anyway, deleting its properties is not an issue.
> 
>> 
>> Modern garbage collector are complex heuristic-based beasts that try to make good trade-offs between latency (how long does an object continue to consume storage after it actually becomes unreferenced)  and performance (how much of the total processing cycles is consume trying to recover unreferenced objects).  Each implementation’s GC uses different heuristics to optimize that trade-off.  Thus when any given object would will be observably GC'ed is non-deterministic between implementations (and often even within a particular implementation).
>> 
> 

consider:

var ref = {x: null};  //ref count of object is 1
ref.x=ref;    //ref count of object is 2; 
ref = null;    //after internally calling deleteReferenceTo, ref count of object is 1.
//  the object is now unreachable, but has a non-zero reference count. It has not been deallocated

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160713/39212529/attachment.html>