|
|
|
|
|
by Araq
3553 days ago
|
|
Good questions. I'm afraid the documentation is seriously out of date about the GC: It used to implement a variant of "trial deletion" so that "never scans the whole heap" used to refer to the fact that it doesn't use traditional mark&sweep, but only scans the subgraph(s) leading to the cycles. Of course you can always create a "subgraph" that spans the whole heap, so even for trial deletion it is a dubious claim. Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC to collect cycles. Reasons: Trial deletion in practice is much slower. For all versions of the GC is stack is scanned conservatively as precise stack scanning is simply too expensive when C is your main target. |
|
But to ask a pointed question, doesn't that mean Nim gets the worst of both worlds? You have both the overhead of updating reference counts and the (relatively long) garbage collection pauses. I guess if the programmer codes in such a way that no cyclic garbage is created it is not a problem because the gc will never be triggered. But how common is that in practice? Does the language make it easy to avoid cycles?