5 ms·

I just don’t understand why there aren’t more languages using automatic reference counting as featured in modern Objective-C and Swift. ARC has very low overhea

by zoul 11y ago

I just don’t understand why there aren’t more languages using automatic reference counting as featured in modern Objective-C and Swift. ARC has very low overhead and predictable performance profile (no GC waking up to choke your app for hundreds of ms). I think it makes almost no sense to consider going back to manual memory management because of performance, not even in games. Unless you are writing for some quite limited embedded hardware.

tamana 11y ago
Is ARC actually safe from memory leaks? CMS GC doesn't choke your all for 100ms
- whyever 11y ago
  I think you can leak memory by having cycles.
- setpatchaddress 11y ago
  No, you can still have memory leaks with ARC. In practice, the GC Apple was using prior to ARC could collect cycles, but it consumed a nontrivial number of CPU cycles compared to ARC. Apple's tools people seem to be unconvinced that GC is efficient enough for production use on slow CPUs.
pcwalton 11y ago
Because atomic reference counting has much worse throughput than tracing GC. This has been known for a long time. It makes sense for Swift because of Swift's unique constraints—interoperability with an atomic-reference-counted world (Objective-C) and, less importantly, mobile UIs putting demands on latency. But most applications would be better off with a tracing GC.
- AlisdairO 11y ago
  > Because atomic reference counting has much worse throughput than tracing GC. This has been known for a long time. I know this to be true for ubiquitously heap allocated systems, but I'm curious if this has been studied extensively for stack+heap reference counted systems, where only a relatively small number of items are heap allocated? Seems like reference counting would gain in this kind of environment, as the stack effectively gives you many of the advantages generational gcs enjoy from their nursery, and you don't have to worry about write boundaries, tracing and the like.

by zoul 11y ago

tamana 11y ago

Is ARC actually safe from memory leaks? CMS GC doesn't choke your all for 100ms

whyever 11y ago
I think you can leak memory by having cycles.
setpatchaddress 11y ago
No, you can still have memory leaks with ARC. In practice, the GC Apple was using prior to ARC could collect cycles, but it consumed a nontrivial number of CPU cycles compared to ARC. Apple's tools people seem to be unconvinced that GC is efficient enough for production use on slow CPUs.

pcwalton 11y ago

Because atomic reference counting has much worse throughput than tracing GC. This has been known for a long time. It makes sense for Swift because of Swift's unique constraints—interoperability with an atomic-reference-counted world (Objective-C) and, less importantly, mobile UIs putting demands on latency. But most applications would be better off with a tracing GC.

AlisdairO 11y ago
> Because atomic reference counting has much worse throughput than tracing GC. This has been known for a long time. I know this to be true for ubiquitously heap allocated systems, but I'm curious if this has been studied extensively for stack+heap reference counted systems, where only a relatively small number of items are heap allocated? Seems like reference counting would gain in this kind of environment, as the stack effectively gives you many of the advantages generational gcs enjoy from their nursery, and you don't have to worry about write boundaries, tracing and the like.