> Not always, but often enough that an introductory article that presents an overview of different memory managment techniques should maybe use the longer name to avoid confusion.
Referring to garbage collection as tracing garbage collection creates more confusion and should be avoided.
It confuses folks into thinking that there is some garbage collection that isn’t tracing. There’s no such thing.
> What's your opinion on the term "RC with cycle detection" that some use for things like Python's GC?
Depends on how you detect cycles. Python uses a garbage collector. Therefore I would say that python has a GC and is a GC’d language.
> Moving to a conservative GC might also introduce memory leaks, if you're unlucky.
Folks who adopt conservatism in production do so only if they have a story for avoiding those leaks. (That’s what we did in JavaScriptCore.)
> But yes, "tracing" gc and rc obeviously behave very differently, and have very different performance considerations.
Just call it “GC” and everyone will know what you mean. No need to be a contrarian and put “tracing” in front.
And it’s not perf considerations if it’s the difference between your program running at all and crashing. Failing to collect all cycles as RC does would cause a program written in a GC’d language to simply crash if it ran for more than just a short while. Failing to invoke destructors the way RC’d programs expect, which would happen if you tried to switch to GC, will cause observably different behavior in addition to possible performance issues.
