9

We sometimes hear "Swift doesn't do classic (tracing) GC, it uses ARC."

But I'm not sure if there is anything in the Swift semantics that requires reference counting. It seems that one could build one's own Swift compiler and runtime to use tracing GC.

So what exactly is "reference-counted" about Swift? Apple's implementation or the language itself? Are there parts of the language or the library that so strongly support ARC that we can use that label for the language itself?

Ray Toal
  • 287
  • 1
  • 7

3 Answers3

10

Swift guarantees that once the last reference to an object is dropped the object is deinitialized, and the deinit code is immediately run.

Obtaining this kind of guarantee through GC is not possible - at least, not without sacrifying performance. Standard GC mechanisms only ensure the deinit code is eventually run, e.g. at the next GC cycle. For precise semantics, you need a reference count somewhere.

chi
  • 14,704
  • 1
  • 31
  • 40
4

chi has answered the specific question in the body about swift, this answer answers the more general question in the title.

Is reference counting GC vs. tracing GC a language property or an implementation property?

reference counting GC and tracing GC provide the programmer with different gaurantees.

Reference counting provides determinism in the location in the program flow where an object is destroyed, that can be important if the object owns scarce resources that must be freed quickly. On the other hand it can't deal with cycles of "strong" references.

It is up to the specification of an individual language what if any characteristics are gauranteed and therefore which choices are available to a compliant implementation.

Peter Green
  • 235
  • 1
  • 5
1

You could take the language known as Swift and rename it to "Swift with ARC". You could then create a new language named "Swift with GC" with exactly the same syntax, but with fewer guarantees about when objects are deallocated.

In Swift with ARC, once the reference count is 0, the object will go. With garbage collection, as long as you have a weak reference, you could assign that weak reference to a strong reference to "recover" the object. (In Swift, once the reference count is 0, weak references are nil); that is a major difference.

And of course Swift with ARC guarantees that killing the last reference count will deallocate the object immediately. For example, you might have a FileWriter class, where you are not allowed to have two instances writing to the same file in existence at the same time. In Swift with ARC you could say oldWriter = nil; newWriter = FileWriter (...) and you would know that the new FileWriter is only created after the old one is deleted (unless you kept another reference around); in Swift with GC this wouldn't work.

Another difference is that in "Swift with ARC", objects that are only referenced through strong reference cycles, but not actually reachable, are guaranteed to be not deallocated.

gnasher729
  • 32,238
  • 36
  • 56