10 ms·

Any other languages that use Automatic Reference Counting? Is ARC strictly better than GC? (Sorry for the question, I am not an iOS, Mac dev.)

DrJokepu 12y ago
In my opinion, if you understand how memory management works, ARC is definitely superior to GC. There are things it's not very good at, typically things that usual reference counting is not very good at either, such as handling cyclical data structures.
- danbruc 12y ago
  Resource management is a necessary evil but usually not a primary concern of most applications. Therefore in an ideal world it should be abstracted away and you should not have to care about it ever. In this respect I consider a full blown garbage collector as closer to the ideal than automatic reference counting. But automatic reference counting is of course also a kind of automatic garbage collection mechanism, just with a bit of a different focus. All solutions are not optimal, but unless you have really many allocations and dealloctions going on, have tight resource constraints or hard timing constraints, current garbage collectors are really good enough. Not that you can not shoot your feet by accidentally keeping large object graphs alive, but that is easy to detect, though sometimes hard to fix. Some developers seem to have some kind of resentments against garbage collectors because real developers of course manage their resources on their own, but many of their arguments are not well founded. Garbage collectors nondeterministically pausing program execution to free unused resources is a common point, but they usually don't realize that automatic reference counting has the same problem - you never know when a reference count drops to zero and triggers the deallocation of the object possibly with a large object graph attached.
  - jahewson 12y ago
    Not true. A reference counted program is deterministic, it is known in advance for a given set of inputs exactly when deallocation will occur. Also, its not really fair to sweep "hard timing constraints" under the rug as a minority use case when these are essential for smooth modern GUIs. Sure, GC is pretty much ideal in terms of absolving developers of resource management responsibilities, but it comes with some significant downsides which can easily effect the final product and should be understated. Rust is a great example of a new language which avoids GC for this reason.
    - pjmlp 12y ago
      You cannot know how much the deallocation impact will be, if a big datastructure is getting its count to 0.
      - jahewson 12y ago
        Of course you can know that, because you know the type of every object. If you're deallocating a big data structure, then the impact will be big. Its easy to choose not to deallocate such objects at an inconvinient time by holding references to them. Compare this with GC where the collection can occur at any time after deallocation, e.g. during an animation.
        danbruc 12y ago
        You can do almost the same with a garbage collector - keep references alive until a convenient point is reached, than kill those last references and manually force a collection. Not that it seems a good idea, but if you need a level of control as described by you, then you are already actively fighting against automatic reference counting and there seems no point to use any kind of automatic resource management in the first place, at least for the relevant objects.
        jahewson 12y ago
        It's not possible to do that in Java, though it would work in C#. Retaining references really is not "fighting against automatic reference counting", it's the opposite: the reference clearly and unambiguously defines the lifetime of the object, including deallocation. This is by design and ARC can still be used for any shared references to the object. Forcing GC on the other hand, would be fighting against it because you're circumventing its usual operation.
        Skinney 12y ago
        It wouldn't work reliably in C# either. Both platforms allow you to inform the GC that now would be a good time to collect, but in both systems the GC can ignore your advice. C# has structs which will try to allocate on the stack, but that is potentially a big (or impossible) refactoring on your program (unless you plan ahead).
  - blub 12y ago
    Garbage collectors don't solve the problem of "resource" management, but of memory management. Languages like Java have mechanisms such as try with resources (not available in Android) or try finally blocks which seem error prone to me, since the programmer has to know that that particular resource should be released explicitly. They also make developers lazy, they get used to not thinking about object lifetimes and the costs of allocation. YMMV of course.
    - mike_hearn 12y ago
      Try with resources is available in Jellybean+
mikaraento 12y ago
Perl, Visual Basic 6 and to some extent Python are examples of languages using the moral equivalent of ARC.
- jimrandomh 12y ago
  Python has been garbage collected since 2.0. (Edit: Perl is garbage collected since version 6, and Visual Basic is garbage collected since version 7. I am not aware of any language besides Objective C moving in the opposite direction.)
  - rsynnott 12y ago
    C++ and Rust both provide reference counting pointer-like-things (shared_ptr and Rc respectively). C++ has been around for quite a while, of course, but Rust is pretty new, and deliberately eschewed garbage collection.
    - pjmlp 12y ago
      C++ RC requires good behavior from whole developers in the team and third party libraries. It is hard to get right with existing code bases. Additionally C++11 got a GC API, but requires explicit programmer control. http://www.stroustrup.com/C++11FAQ.html#gc-abi http://www.stroustrup.com/C++11FAQ.html#gc-abi C++'s memory model is tainted by C's compatibility, as such it is quite limited in the GC algorithms that can be implemented.
      - coliveira 12y ago
        In C++, reference counting is in a per object basis. There is no need of cooperation at all from other libraries or code bases.
        pjmlp 12y ago
        Really?!? How can you guarantee that the component library that your company just bought, available only in binary form isn't doing something like this? void cool_stuff_with_widget(const std::shared_ptr<UI> ptr) { UI* evilPtr = const_cast<UI*>(ptr->get()); // now store evilPtr somewhere else and try to use it any time the library feels like it } No one is going through disassembly to check such behaviors. C++ RC is a very welcoming addition to the language, but it only works if everyone plays by the rules, 100% of the time.
jakobegger 12y ago
The most important difference on OS X is that ARC is compatible with retain/release, but GC requires explicit support by every framework linked in your app. Some frameworks never added GC compatibility. In the general case, it is estimated that GC uses on average twice as much memory (high water mark), but direct comparisons are of course very application specific. GC also has the dreaded collection pauses which can make performance unreliable. (Eg stuttering animations) Biggest drawback of ARC is that it doesn't detect cycles, so the developer needs to have a global understanding of an app to avoid hard to debug leaks.
xenadu02 12y ago
Yes, ARC is better. Objective-C is a superset of C. If you think about what it means to have a garbage-collected version of C for just a few minutes it should become immediately clear why abandoning GC for Objective-C is necessary and appropriate. The GC can't always reliably detect a reference (pointer) so it has to be conservative. It also can't compact the heap, which means you don't get the nice "allocation is just advancing a pointer" behavior that makes allocations nearly instantaneous in managed languages. ARC is essentially just the old rules for manual reference counting (MRC), but the compiler analyzes your code and inserts the retain/release/autorelease calls automatically. This gives you similar deterministic behavior as MRC but while writing the code it feels like a garbage collected language because you mostly ignore management of memory and everything "just works". The downside to ARC is the inability to detect retain cycles and a slight performance hit compared to MRC in some scenarios. The performance is actually pretty good... What ARC loses compared to hand-coding it gains by using special runtime functions (not slower ObjC message sends) that elide unnecessary retain/release calls in many situations. objc_retainAutoreleaseReturnValue is inserted in a caller and callee (typically a property getter). It examines the return address on the stack to detect if the caller is going to invoke objc_retainAutoreleaseReturnValue on the returned value; if so it just does a retain and sets a flag the caller uses to skip doing retain+autorelease, leaving the caller's release only. Instead of the object staying alive until the next run loop iteration and getting autoreleased it can safely be released immediately, plus at least one extra pair of function calls can be eliminated.
asveikau 12y ago
In C++, shared_ptr and similar "smart pointer" concepts are very similar to ARC. The key difference is it's a library feature, built atop destructors and copy-constructors, and not a language change like ARC. Microsoft's C++/CX introduced in 2011 is also very similar; the hat syntax[1] is to COM's AddRef/Release as ARC is to -retain/-release. In both schemes, what used to be manually refcounted objects are now managed by the compiler. I don't recommend C++/CX though, it is confusing to C++ devs. Smart pointers are a better recognized idiom. [1] Unrelated to the hat syntax from MS's previous attempts, Managed C++ and C++/CLI, which are GC and not refcounting as in C++/CX.

DrJokepu 12y ago

In my opinion, if you understand how memory management works, ARC is definitely superior to GC. There are things it's not very good at, typically things that usual reference counting is not very good at either, such as handling cyclical data structures.

danbruc 12y ago
Resource management is a necessary evil but usually not a primary concern of most applications. Therefore in an ideal world it should be abstracted away and you should not have to care about it ever. In this respect I consider a full blown garbage collector as closer to the ideal than automatic reference counting. But automatic reference counting is of course also a kind of automatic garbage collection mechanism, just with a bit of a different focus. All solutions are not optimal, but unless you have really many allocations and dealloctions going on, have tight resource constraints or hard timing constraints, current garbage collectors are really good enough. Not that you can not shoot your feet by accidentally keeping large object graphs alive, but that is easy to detect, though sometimes hard to fix. Some developers seem to have some kind of resentments against garbage collectors because real developers of course manage their resources on their own, but many of their arguments are not well founded. Garbage collectors nondeterministically pausing program execution to free unused resources is a common point, but they usually don't realize that automatic reference counting has the same problem - you never know when a reference count drops to zero and triggers the deallocation of the object possibly with a large object graph attached.
- jahewson 12y ago
  Not true. A reference counted program is deterministic, it is known in advance for a given set of inputs exactly when deallocation will occur. Also, its not really fair to sweep "hard timing constraints" under the rug as a minority use case when these are essential for smooth modern GUIs. Sure, GC is pretty much ideal in terms of absolving developers of resource management responsibilities, but it comes with some significant downsides which can easily effect the final product and should be understated. Rust is a great example of a new language which avoids GC for this reason.
  - pjmlp 12y ago
    You cannot know how much the deallocation impact will be, if a big datastructure is getting its count to 0.
    - jahewson 12y ago
      Of course you can know that, because you know the type of every object. If you're deallocating a big data structure, then the impact will be big. Its easy to choose not to deallocate such objects at an inconvinient time by holding references to them. Compare this with GC where the collection can occur at any time after deallocation, e.g. during an animation.
      - danbruc 12y ago
        You can do almost the same with a garbage collector - keep references alive until a convenient point is reached, than kill those last references and manually force a collection. Not that it seems a good idea, but if you need a level of control as described by you, then you are already actively fighting against automatic reference counting and there seems no point to use any kind of automatic resource management in the first place, at least for the relevant objects.
        jahewson 12y ago
        It's not possible to do that in Java, though it would work in C#. Retaining references really is not "fighting against automatic reference counting", it's the opposite: the reference clearly and unambiguously defines the lifetime of the object, including deallocation. This is by design and ARC can still be used for any shared references to the object. Forcing GC on the other hand, would be fighting against it because you're circumventing its usual operation.
        Skinney 12y ago
        It wouldn't work reliably in C# either. Both platforms allow you to inform the GC that now would be a good time to collect, but in both systems the GC can ignore your advice. C# has structs which will try to allocate on the stack, but that is potentially a big (or impossible) refactoring on your program (unless you plan ahead).
- blub 12y ago
  Garbage collectors don't solve the problem of "resource" management, but of memory management. Languages like Java have mechanisms such as try with resources (not available in Android) or try finally blocks which seem error prone to me, since the programmer has to know that that particular resource should be released explicitly. They also make developers lazy, they get used to not thinking about object lifetimes and the costs of allocation. YMMV of course.
  - mike_hearn 12y ago
    Try with resources is available in Jellybean+

mikaraento 12y ago

Perl, Visual Basic 6 and to some extent Python are examples of languages using the moral equivalent of ARC.

jimrandomh 12y ago
Python has been garbage collected since 2.0. (Edit: Perl is garbage collected since version 6, and Visual Basic is garbage collected since version 7. I am not aware of any language besides Objective C moving in the opposite direction.)
- rsynnott 12y ago
  C++ and Rust both provide reference counting pointer-like-things (shared_ptr and Rc respectively). C++ has been around for quite a while, of course, but Rust is pretty new, and deliberately eschewed garbage collection.
  - pjmlp 12y ago
    C++ RC requires good behavior from whole developers in the team and third party libraries. It is hard to get right with existing code bases. Additionally C++11 got a GC API, but requires explicit programmer control. http://www.stroustrup.com/C++11FAQ.html#gc-abi http://www.stroustrup.com/C++11FAQ.html#gc-abi C++'s memory model is tainted by C's compatibility, as such it is quite limited in the GC algorithms that can be implemented.
    - coliveira 12y ago
      In C++, reference counting is in a per object basis. There is no need of cooperation at all from other libraries or code bases.
      - pjmlp 12y ago
        Really?!? How can you guarantee that the component library that your company just bought, available only in binary form isn't doing something like this? void cool_stuff_with_widget(const std::shared_ptr<UI> ptr) { UI* evilPtr = const_cast<UI*>(ptr->get()); // now store evilPtr somewhere else and try to use it any time the library feels like it } No one is going through disassembly to check such behaviors. C++ RC is a very welcoming addition to the language, but it only works if everyone plays by the rules, 100% of the time.

jakobegger 12y ago

The most important difference on OS X is that ARC is compatible with retain/release, but GC requires explicit support by every framework linked in your app. Some frameworks never added GC compatibility. In the general case, it is estimated that GC uses on average twice as much memory (high water mark), but direct comparisons are of course very application specific. GC also has the dreaded collection pauses which can make performance unreliable. (Eg stuttering animations) Biggest drawback of ARC is that it doesn't detect cycles, so the developer needs to have a global understanding of an app to avoid hard to debug leaks.

xenadu02 12y ago

Yes, ARC is better. Objective-C is a superset of C. If you think about what it means to have a garbage-collected version of C for just a few minutes it should become immediately clear why abandoning GC for Objective-C is necessary and appropriate. The GC can't always reliably detect a reference (pointer) so it has to be conservative. It also can't compact the heap, which means you don't get the nice "allocation is just advancing a pointer" behavior that makes allocations nearly instantaneous in managed languages. ARC is essentially just the old rules for manual reference counting (MRC), but the compiler analyzes your code and inserts the retain/release/autorelease calls automatically. This gives you similar deterministic behavior as MRC but while writing the code it feels like a garbage collected language because you mostly ignore management of memory and everything "just works". The downside to ARC is the inability to detect retain cycles and a slight performance hit compared to MRC in some scenarios. The performance is actually pretty good... What ARC loses compared to hand-coding it gains by using special runtime functions (not slower ObjC message sends) that elide unnecessary retain/release calls in many situations. objc_retainAutoreleaseReturnValue is inserted in a caller and callee (typically a property getter). It examines the return address on the stack to detect if the caller is going to invoke objc_retainAutoreleaseReturnValue on the returned value; if so it just does a retain and sets a flag the caller uses to skip doing retain+autorelease, leaving the caller's release only. Instead of the object staying alive until the next run loop iteration and getting autoreleased it can safely be released immediately, plus at least one extra pair of function calls can be eliminated.

asveikau 12y ago

In C++, shared_ptr and similar "smart pointer" concepts are very similar to ARC. The key difference is it's a library feature, built atop destructors and copy-constructors, and not a language change like ARC. Microsoft's C++/CX introduced in 2011 is also very similar; the hat syntax[1] is to COM's AddRef/Release as ARC is to -retain/-release. In both schemes, what used to be manually refcounted objects are now managed by the compiler. I don't recommend C++/CX though, it is confusing to C++ devs. Smart pointers are a better recognized idiom. [1] Unrelated to the hat syntax from MS's previous attempts, Managed C++ and C++/CLI, which are GC and not refcounting as in C++/CX.