3 ms·

Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither obj

Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.

anextio 13y ago
Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.
- sillysaurus3 13y ago
  How is it possible to use refcounting for GC while also correctly handling cyclic references? EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-automatic-reference-counting-in-objective-c-not-prevent/6388601#6388601 http://stackoverflow.com/questions/6260256/what-kind-of-leak... From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original." Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-difference-between-objective-c-automatic-reference-counting-and-garb/7894809#7894809 http://stackoverflow.com/questions/7874342/what-is-the-diffe... It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.
- mikeash 13y ago
  I wouldn't say "no problems here" at all. Memory management errors are extremely common in Objective-C code. This is true even with ARC. The problems can be solved, but they are certainly there. The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.
pornel 13y ago
You don't need to automatically solve all the problems to get a safer language than C/C++. I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.

anextio 13y ago

Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.

sillysaurus3 13y ago
How is it possible to use refcounting for GC while also correctly handling cyclic references? EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-automatic-reference-counting-in-objective-c-not-prevent/6388601#6388601 http://stackoverflow.com/questions/6260256/what-kind-of-leak... From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original." Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-difference-between-objective-c-automatic-reference-counting-and-garb/7894809#7894809 http://stackoverflow.com/questions/7874342/what-is-the-diffe... It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.
mikeash 13y ago
I wouldn't say "no problems here" at all. Memory management errors are extremely common in Objective-C code. This is true even with ARC. The problems can be solved, but they are certainly there. The question of cycles is even more pertinent with ARC, because it's easy to get used to letting the compiler do everything for you, and it's easy to miss an occasional leak of a cyclic object graph.

pornel 13y ago

You don't need to automatically solve all the problems to get a safer language than C/C++. I don't think cyclic object graphs are needed to, say, respond to a TLS heartbeat without out-of-bounds reads.