> That sounds interesting. What was the name of the GC? Did it fail in
> single-threaded progs and were failures very rare ("almost zero probability")
> ? When was it observed the very first time? Could you fix it easily?
It was
[https://www.researchgate.net/publication/2534368_A_Pure_Reference_Counting_Garbage_Collector](https://www.researchgate.net/publication/2534368_A_Pure_Reference_Counting_Garbage_Collector)
You cannot mix the cycle candidate detection with deferred reference counting
as the paper suggests you can. Proof:
proc leak() =
var n: Node
new(n)
n.next = n # produce a cycle
# n's RC is 1 after this assignment.
for i in 0..10_000:
leak()
Run
Since `n` is on the stack, itself is not RC'ed. There is no `decref` operation
that could detect a RC > 0, these nodes are not considered to be cycle
candidates even though they are cyclic. Eventually the ZCT loses them and then
they are gone for good.
> How safe is the GC in Swift (another refcounted language) and has it the same
> difficulties? Are all refcounted GCs inherently unsafe? (as long as cyclic
> references are involved, I guess, this is the main issue....)
The issue here is the interaction of the cycle detector with the "deferred RC"
optimization. Swift lacks both.
