That reference counting is done at runtime. It’s a runtime garbage collector. It’s different than a generational GC, but it’s GC. Those cycles to increment and decrement a counter attached to every object at ever touch aren’t free. All the downvotes in the world won’t make that free.
What does "it" refer to? The function calls to _swift_release_()? Because if function calls are a "garbage collector," then free() is a garbage collector. And if free() is a garbage collector, then the term is too vague to have any useful meaning.
Yes. Garbage collectors also call free. They call functions. They do all kinds of things. They even increment and decrement reference counters on your behalf. When there’s a system that manages your memory for you at runtime, that’s a garbage collector.
Swift is great. And reference counting is exactly the right kind of GC for UIs because there are no pauses. But GC it still is. And it wrecks throughput and is not appropriate for situations where you don’t want GC.
And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually. Swift is like C++ or Rust if you were never allowed to have a reference to anything that wasn't behind an Arc. Then it's no longer manual, it's automatic.
> Yes. Garbage collectors also call free. They call functions.
Ok, what is calling `free` here? Point to the garbage collector. Show me the thing that is collecting the garbage.
> And in reference to `shared_ptr`, or Rc and Arc in Rust, that's manual memory management because you're doing it... manually.
You're also doing it manually when you decide to make a type a class in Swift. You're opting in to reference counting when you write a class, or use a type that is backed by a class.
It also seems that our goalposts have gone missing. Before, "it" (whatever "it" is) was a garbage collector because it happened at runtime:
> That reference counting is done at runtime. It’s a runtime garbage collector.
shared_ptr, Rc, and Arc also manage their memory at runtime. But now, "it's" a garbage collector because the compiler generates the retain/release calls...
The garbage collector is what wraps every reference to every object on the heap.
But fine, no GC. I wonder why every language in the world doesn’t use reference counting, since it’s not GC AND you don’t have to clean up any memory you allocate. I guess everyone who ever designed a language is kinda dumb.
> And reference counting is exactly the right kind of GC for UIs because there are no pauses.
That's not the reason it uses reference counting. The overhead of scanning memory is too high, the overhead of precisely scanning it (avoiding false-positive pointers) is higher, and the entire concept of GC assumes memory can be read quickly which isn't true in the presence of swap.
That said, precise GC means you can have compaction, which can potentially be good for swap.
I thought Swift uses ARC just like Objective-C? The compiler elides much of the reference counting, even across inlined functions. It’s not like Python or Javascript where a variable binding is enough to cause an increment (although IIRC the V8 JIT can elide some of that too).
I don’t disagree that it’s a runtime GC but there’s a bit of nuance to its implementation that resists simple categorization like that.
