No, but ARC does not have to pause all threads. Also this exists:

https://developer.apple.com/documentation/swift/unsafemutabl...

So your scenario there is a separate thread that doesn't generate or free garbage? Because if it does, there will be synchronization inside malloc/free and your thread will pause. Also the Swift compiler is unpredictable about when it will use the heap instead of stack, allocations are not explicit. So it might be hard to accomplish in practice.

I agree that this special case could be more realtime with ARC, but on other GCs such an isolated worker can be implemented as a separate program instance (separate process or separate VM instance in same process) that has memory allocation and GC disabled after init.

In the other cases where you keep whe GC on, I think the low-pause GCs of today should be suitable for tasks like computer vision in cars because the pause times are so short (sub-millisecond) vs the processing time for a frame. And the generally higher performance of non-rc GC should more than make up for it.

Swift has no GC, just ARC (automatic refcounting).

Swift has a GC, what it doesn't have is a tracing GC.

Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, which can optimize away redundant redundant reference count operations.

Typically one refers to the CS definition of automatic memory management, using accredited references like "The Garbage Collection Handbook: The Art of Automatic Memory Management".

Everything from "ARC" is there on chapter 5.

In your division, ARC is stop-the-world variety because things like cascading deallocations cause unbounded work.