Feature-Request: allow to iterate over WeakSet / WeakMap

[Michael Kriegel]

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?

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:

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).
>

Sure and that is good as it is. Weak references as I'd like to see them, 
would depend on the information, whether there is still a hard reference 
to the object - not whether it has actually been gc'ed. However, I'll 
have to take a deeper look into thegc topic to find out, whether there 
is no way to find that out - still please note the first question in 
this message: does the requested feature make sense?

On my opinion: yes, because when the user can declare weak references 
explicitely, he can rely on that an object will be gc'ed even though he 
still has a weak reference to it. Of course he has to assure, that the 
resource still "exists":

let x = {};
let weak y = x

function someFunctionWhichUsesY() {
   if (y) y['a']++;
   // maybe: else throw ...
}

function someOtherFunctionWhichDeletesTheOnlyHardReferenceToX() {
   x = {'a':0}; // user may not have noticed, that y is still pointing 
to the original object - but as y is weak, it will be undefined from now 
on -> no memory leak.
}

If the user forgets to check for y's existence and 
someOtherFunctionWhichDeletesTheOnlyHardReferenceToX has been called 
before, an exception, but that is much better than having a memory leak 
(if you ask me). Again: On my opinion a weak reference should return 
undefined as soon as there is no hard reference to the object anymore, 
not as soon as the object becomes gc'ed.

>
> If you want to drill deep into how garbage collectors work, there are 
> lots of good resources at http://www.memorymanagement.org/index.html
>
>
> Allen
>

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