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