2 ms·

Unlike other resources, dangling references to memory are catastrophic. They generally go undetected (no layer of indirection to invalidate them) and can arbitr

Unlike other resources, dangling references to memory are catastrophic. They generally go undetected (no layer of indirection to invalidate them) and can arbitrarily corrupt any future object, violate any type safety rules of the platform, and make even bug-free code execute incorrectly. "Is this object really dead?" is the kind of mind-numbing but critically important question that computers demonstrably answer much more reliably than people. That's why even objc uses a simple but expensive form of garbage collection (reference counting) rather than making you declare "not only am I not using this, I hereby bet my reputation that nobody else is either" by calling free().

saurik 15y ago
The idea of type-safety has nothing to do with this: a type-safe language implemented entirely with reference counting, having no ability to write to arbitrary memory locations on purpose or on accident, has this same tradeoff. Additionally, as I think this is also relevant to your comment, if you take a step back for a second from the notion that an object /is/ memory, and think of memory as being one of the resources that an object is using, things become more clear. Simply put, we have two common ways of reclaiming objects automatically: garbage collection and reference counting. The tradeoff is that with garbage collection, you get free cycle detection at the cost of not having deterministic finalization. Each of these options has downsides: neither is fundamentally better than the other, and not having either one causes you to have to scratch your head occasionally, or add extra code to deal with the lack of automation. (edit:) Thinking about this overly simple description, I realize that I'm over-simplifying a little too much... a lot of the fundamental problem has to do with an inability to determine the order of finalization of objects in a cycle, which is what causes a lot of mistakes in Java finalizer implementations. In comparison, the practical problems are that the common implementations involved take extreme positions: if you have a garbage collected language, it normally is not "reference counting with a cycle detector bolted on", which yields a weird property of possibly arbitrary delays on finalization of valuable resources when you aren't under memory pressure.

saurik 15y ago

The idea of type-safety has nothing to do with this: a type-safe language implemented entirely with reference counting, having no ability to write to arbitrary memory locations on purpose or on accident, has this same tradeoff. Additionally, as I think this is also relevant to your comment, if you take a step back for a second from the notion that an object /is/ memory, and think of memory as being one of the resources that an object is using, things become more clear. Simply put, we have two common ways of reclaiming objects automatically: garbage collection and reference counting. The tradeoff is that with garbage collection, you get free cycle detection at the cost of not having deterministic finalization. Each of these options has downsides: neither is fundamentally better than the other, and not having either one causes you to have to scratch your head occasionally, or add extra code to deal with the lack of automation. (edit:) Thinking about this overly simple description, I realize that I'm over-simplifying a little too much... a lot of the fundamental problem has to do with an inability to determine the order of finalization of objects in a cycle, which is what causes a lot of mistakes in Java finalizer implementations. In comparison, the practical problems are that the common implementations involved take extreme positions: if you have a garbage collected language, it normally is not "reference counting with a cycle detector bolted on", which yields a weird property of possibly arbitrary delays on finalization of valuable resources when you aren't under memory pressure.