14 ms·

Mac Apps That Use Garbage Collection Must Move to ARC

104 points by tachion 12y ago

danbruc 12y ago
What is the reasoning behind that? Given the advances over the last decade or two automatic garbage collection is good enough for a lot of scenarios and this looks like a step back. Why not use automatic garbage collection as the default but offer additional means for manual resource management in case it is really needed?
- riffraff 12y ago
  my understanding: they have abandoned garbage collection in Obj-C years ago and think ARC is overall better. And my guess: GC probably doesn't play nice with recent/future changes in OSX memory management (e.g. compressed memory) so the less apps use it the better the whole system is overall. Hence, they probably want to get rid of the whole thing ASAP, forbidding it _for apps submitted to the mac app store_ is a reasonable step in that direction.
- MaxGabriel 12y ago
  Could be they just don't want to support the garbage collector anymore.
- threeseed 12y ago
  Probably because Apple is moving towards a unified iOS/OSX SDK. We have seen evidence of this with the Photos app which uses UXKit (unified AppKit/UIKit). I would imagine that Apple is pushing developers towards this new SDK landscape step by step starting with ARC. There is a precedence for Apple doing this usually related to a new hardware platform e.g. x86, 64-bit and perhaps ARM Macs.
- ttflee 12y ago
  IMHO, they want to get everything that has a UI as responsive as possible. GC in theory is a good feature but it does not guarantee that constant time is used for each mark-and-sweep cycle. And together with multithreading that means uncertainty for rendering every frame of video, which is done in the main thread of an App 60 times per second. And for modern system, anything you see on screen is part of this rendering. Try to think about how could memory shared by main thread and a background thread be GCed. It could turn out to be: halting the process for GC, retaining some memory forever, or implementing some complicated algorithm that is too difficult to debug/maintain.
  - oconnor0 12y ago
    That can be resolved with a different GC.
    - ttflee 12y ago
      Yes, I have heard of some algorithms that consume a lot more memory to balance timing. E.g.: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
    - fidotron 12y ago
      Not really. I've had to deploy lots of soft real time apps on GCed environments over the years, and it's always a problem. You can work around it with things like object pools, but some library or API will assume that the GC is OK and will be quietly spitting out objects continuously which will lead to a GC pause. It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. Even if you're in C++ modern compilers can only make the most out of it if you pass by value, as this enables all sorts of other optimisations to kick in. The key benefit of reference counting is it's predictable. Real time systems are also not strictly the lowest latency, they are defined by predictability. This becomes a preoccupation with minimising your worst case scenario.
      - krschultz 12y ago
        It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. This is simply not true. The API has always been heavily based on Java primitives. They didn't even use enums in the older APIs, preferring instead int constants. (I hate that one personally). GC pauses have always been a point of focus for the Android platform.
- pjmlp 12y ago
  GC never worked properly in Objective-C. Apple failed to produce a working GC that didn't crash all the time, because it required all Objective-C libraries to be compiled the same way. Additionally the C subset only allows for conservative GC, which is not optimal when performance matters. So in the end they went with ARC, with isn't nothing more than having the compiler produce the retain/release calls that Mac OS X frameworks were already expecting anyway. So this has more to do with how technically feasible it is to have a proper GC in Objective-C, than GC in general.
- bitwize 12y ago
  Everything GC can do, ARC can do in strict space and time constraints.
  - danbruc 12y ago
    Plain (automatic) reference counting can not handle cycles without support from developers.
    - blub 12y ago
      I find that a good thing, because developers are trained to think that they have to use weak references and think about object lifetimes. Android developers tend to not think so much about lifetimes which leads to memory leaks because Dalvik apparently can't figure out some of those cycles by itself. Just do a search for "Android memory leak" to see some examples.
      - smrtinsert 12y ago
        A platform with 80% of mobile installations has developers who don't understand object lifecycles Got it.
        kasabali 12y ago
        I guess he meant Android application developers, not the people who wrote Dalvik.
      - tomjen3 12y ago
        Try to parse any tree structure without creating cycles (say the XML/XHTML inside an ebook) - that may be possibly with just one or two devs on the project but as soon as every dev doesn't know every line of code there is an oppertunity for errors and you only need one link to leak memory. That Dalvik can't handle the cycles is stupid but an issue with Dalvik (that is likely to be phased out with the new runtime) not an issue with GC. Computers are really, really, good about executing trivial tasks repeatedly without ever making a stupid mistake, humans not so. And as Terminator taught us: never send a human to do a machines job.
jimrandomh 12y ago
What the fuck? This is a really bad technical decision. As written, it sounds like they're planning to reject garbage collection in-general, which would be a ban on most major programming languages. If you assume they only mean garbage collection in Objective C, it's still a head-scratchingly stupid decision. Modifying an app to not use garbage collection is, in many cases, a major project that will introduce a lot of bugs. And the benefit is... very dubious at best.
- wsc981 12y ago
  I'm pretty sure this notification is only meant for apps using the Objective-C garbage collector, as the notification mentions that the GC was deprecated a while ago. I don't think a lot of Mac developers used the Objective-C GC anyway. Finally Apple mentions the following in it's migration document [0]: Is GC (Garbage Collection) deprecated on the Mac? Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X. Automatic Reference Counting is the recommended replacement technology. To aid in migrating existing applications, the ARC migration tool in Xcode 4.3 and later supports migration of garbage collected OS X applications to ARC. Based on the above statement, my guess is that's Xcode has some build-in tools to convert GC code to ARC code, making the transition easier. --- [0]: https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/ios/releasenotes/Objecti...
- deleted 12y ago
  [deleted]
  - jimrandomh 12y ago
    Er, what? Transitioning from GC to ARC doesn't make code cleaner or reduce bugs. It eliminates GC pauses, which is a slight speedup, but the set of bugs that a garbage-collected program has are roughly a subset of the bugs that a reference-counted program can have.
- tptacek 12y ago
  This is not a ban on garbage-collected programming languages.
zbowling 12y ago
To head off some of the misconceptions here, this is not about garbage collection in general but Objective-C built-in garbage collection. Apple NEEDs to do this for their own sanity. I'm surprised they waited this long actually. It's a serious PITA to support GC and non GC at the same time in a framework. Having to add finalizer methods instead of relaying on dealloc methods and dealing with non-deterministic object lifetime as well as deterministic was a huge problem. ARC doesn't have these problems because it wraps traditional manual reference counting (to pick nits, it actually bypasses it when it can safely but this is an optimization detail that you shouldn't need to worry about). To Apple and 3rd party framework developers, it's painful to support GC and non-GC paths in your code at the sametime. It's not really possible to use a non-GC compatible framework in a GC app. It's also impossible to use ARC and still support the GC as well in the same framework. Apple has been completely prevented from using ARC in it's own frameworks because of keeping GC compatible apps working, and making this change will allow them to start ARC-ifying their own code. It also means that a significant chunk of the ObjC runtime can be simplified. There are also some great advancements in the ObjC runtime that Apple is doing (like tagged pointers and shadow objects) that the reference boehm garbage collector can't really deal with and was all completely disabled in the ObjC runtime when you had a GC app. This is a good thing. Not many app actually shipped with the ObjC garbage collector and ran well. Now you are free to use your GC for your own needs in your app. That has nothing to do with ObjC. Feel free to add Java or Ruby or whatever language you like to your own app and submit that to the Mac App Store.
- deleted 12y ago
  [deleted]
- LeoNatan25 12y ago
  Question is, are they removing support from the OS frameworks themselves or just Mac App Store? There are many applications that still use GC, many of which are not in the store. Does that mean they cut support for these in a future 10.10 update or 10.11? I doubt it.
  - realityking 12y ago
    I'd bet on 10.11 or 10.12. ig they don't eventually remove it, there's little point in deprecating it or forcing it off the App Store as they can not reap the benefits in their own code.
amit_m 12y ago
Does ARC work like reference counting in python? (i.e. a reference count is stored for every object)
- cfrs 12y ago
  Yes, refcount is stored for every object, but ARC is not able to detect cycles.
  - berdario 12y ago
    To help with this, both Python and ObjC have weak references https://docs.python.org/3/library/weakref.html https://docs.python.org/3/library/weakref.html
    - cfrs 12y ago
      AFAIK python have kind of cycles detector enabled by default.
      - berdario 12y ago
        Sort of, CPython has both reference counting and a normal Garbage Collection. You can disable the latter and still avoid memory leaks as long as you don't have cycles
    - dragonwriter 12y ago
      Weak references don't primarily exist to deal with cycles, and cycles generally often involve necessarily strong references even in systems that support weak references. (That is, e.g., cycles where A needs to be reachable if B is reachable and vice versa, such that a weak reference that allowed B to be disposed while A was reachable or vice versa would not be acceptable. A system that can detect cyclic garbage will still be able to collect both A and B -- connected by strong references -- when neither can be reached from the rest of the program.)
      - mst 12y ago
falcolas 12y ago
I wonder how many applications will start leaking memory as a result of this? Cyclic references are not that uncommon in many algorithms, and identifying the need to remove these will be challenging for applications which relied on automatic identification will take time.
- jahewson 12y ago
  Xcode can help with that, as it says in the "Transitioning to ARC Release Notes": > To aid in migrating existing applications, the ARC migration tool in Xcode 4.3 and later supports migration of garbage collected OS X applications to ARC.
- jjoonathan 12y ago
  When it comes to overall ease of use, the importance of tooling dwarfs the importance of GC vs RC, and apple has had really solid RC tooling for a while. It graphs memory usage, searches out leaked objects (by injected GC or by diffs), lists them, lists the retain/release events with timestamps, and lets you jump to the responsible code with a single click. Compare that to the nightmare of trying to get a misbehaving GC to cooperate and suddenly it doesn't seem so crazy. EDIT: Or at least they had such tools 5-6 years ago, regression is certainly possible. For unrelated reasons I've been playing in other playgrounds for the last 5-6 years so I can't say for sure.
userbinator 12y ago
I'm not so familiar with the Mac ecosystem, but is it really true that Apple decides what languages you can use to write your apps in?
- parasubvert 12y ago
  No. You can write it in whatever you want (even on iOS these days) though you can't depend on any third party pre-installations. IOW you need to be able to vendor in your 3rd party language and library dependencies, and use a thin Objective-C wrapper to make the whole thing natively executable. This announcement is more about a feature in Objective-C being actively discouraged by refusing to distribute your app on their store. You can still use it if you distribute your app on your own.
  - jimrandomh 12y ago
    > No. You can write it in whatever you want (even on iOS these days) This is somewhat misleading. Apple bans all use of JIT compilation on iOS, which de facto eliminates languages that depend on it.
    - greggman 12y ago
      I thought they just banned the use of code not embedded in your app. You are free to Jit. Just not files downloaded from the net. Only files embedded In your app
      - Ecco 12y ago
        No you can't jit. For a very simple reason: you cannot allocate memory that is both writable and executable.
      - wging 12y ago
        For those who are wondering, you can still use an embedded webview, which does end up doing just-in-time compilation of javascript.
philippnagel 12y ago
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.
jakobegger 12y ago
This is a pity. I have an app that uses ARC on 64bit, and GC on 32bit. Allowed me to ditch manual memory management without dropping support for 32bit machines.
- FigBug 12y ago
  Is there still demand for 32 bit apps? The last 32-bit mac was released in 2006 and the last OS 32 bit OS in 2009?
  - delinka 12y ago
    The most recent version of Microsoft Office for OS X is still 32-bit, still uses the deprecated event system, and still uses deprecated file I/O functions ... Remember resource forks?
    - mglinski 12y ago
      The most recent released version of Office for Mac is also from 2010.
    - FigBug 12y ago
      If I wasn't clear, my question was the opposite, not is there still demand to run 32-bit software, but is there demand for new 32-bit software from people who can't run 64-bit. I've assumed anybody with a almost 10 year old computer doesn't get that much new software. I tend to release supporting the last 2 or 3 OS releases and 64-bit only and haven't received any complaints.
      - delinka 12y ago
        I did indeed misinterpret. To answer that way, I'm not personally aware of anyone demanding new apps targeted to 32-bit on OS X. As an OS X developer, I'm averse to the idea of starting a new app with that as a target.
  - jakobegger 12y ago
    I still use my 2006 iMac occasionally, so I care. Macs live a lot longer than phones. However, you are right, there is little demand for 32bit software; my newer apps require 64bit. But I see no reason to cut off support in an old product.
zomgbbq 12y ago
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html https://developer.apple.com/library/ios/documentation/Swift/...
tacos 12y ago
Awesome. Now all they gotta do is stop treating strings like we're in a Pascal Intro to Computer Science class circa 1987 and we gots ourselves a kick ass development environment here. :)
jeffsco 12y ago
What Apple calls "automatic reference counting" is what is usually known as just "reference counting." They call it "automatic" to distinguish it from the previous, even cruder, system where counts were manipulated directly by the programmer. Obviously this is an improvement, but personally I am a supporter of GC. It is a myth that reference counting is not subject to arbitrary pauses: http://www.hboehm.info/gc/myths.ps http://www.hboehm.info/gc/myths.ps
- TheLoneWolfling 12y ago
  Incorrect. You can, although I haven't seen systems that do this, enqueue objects to be deallocated then have either the main thread every once in a while or a background thread periodically pop objects off of the queue and do the normal reference counting dance.
  - mst 12y ago
    This is pretty much what the perl5 VM does on scope exit to blow away unused temporaries. Weak references take a while to figure out but once you have, refcounting is so much more predictable than GC.
  - gchpaco 12y ago
    Yup, the problem with this is that it renders the other claimed advantage of reference counting moot (viz. there is now little or no temporal linkage between when the object's ref count hits 0 and when its destructor/finalizer is called). The other problem with reference counting, which is I believe insoluble, is that it is inherently O(alldata); that is to say you must perform an operation each time a piece of memory dies, at the very least. This makes it good for collecting older generations in a generational GC (where O(alldata) ~= O(livedata)) but bad for the nursery (where the generational assumption means that O(livedata) << O(alldata)).
    - TheLoneWolfling 12y ago
      Any computer processor can do a finite number of operations per time period, and an (effectively) arbitrary number of objects can be marked for deallocation simultaneously. So yes, you can have arbitrary delays. But this is always the case. Refcounting, GC, manual memory management, etc. But I'd say you've gone one step too far in saying that there is little or no temporal linkage with refcounting. If you're using a queue, objects will be cleaned up as soon as they can be while remaining inside the time limitations you've allowed. If you want to get fancy, you can even have the compiler rearrange objects such that pointers that are likely to point to objects with destructors are first in line. And yes, refcounting is O(alldata). But that's ignoring that freeing is relatively fast, and that you can easily implement bunches and bunches of optimizations to prevent refcounting from having to work at all.(For example: if you acquire a reference to an object on the same thread and then release it, you don't have to do anything. If you create an object, but at runtime you can determine that you never released the reference to anything, you can free it immediately. If you acquire multiple references to an object, you only need to check for references reaching zero once. Etc. All of these are things that theoretically can be done with a standard GC, but good luck actually doing so.)

104 points by tachion 12y ago

What is the reasoning behind that? Given the advances over the last decade or two automatic garbage collection is good enough for a lot of scenarios and this looks like a step back. Why not use automatic garbage collection as the default but offer additional means for manual resource management in case it is really needed?

riffraff 12y ago
my understanding: they have abandoned garbage collection in Obj-C years ago and think ARC is overall better. And my guess: GC probably doesn't play nice with recent/future changes in OSX memory management (e.g. compressed memory) so the less apps use it the better the whole system is overall. Hence, they probably want to get rid of the whole thing ASAP, forbidding it _for apps submitted to the mac app store_ is a reasonable step in that direction.
MaxGabriel 12y ago
Could be they just don't want to support the garbage collector anymore.
threeseed 12y ago
Probably because Apple is moving towards a unified iOS/OSX SDK. We have seen evidence of this with the Photos app which uses UXKit (unified AppKit/UIKit). I would imagine that Apple is pushing developers towards this new SDK landscape step by step starting with ARC. There is a precedence for Apple doing this usually related to a new hardware platform e.g. x86, 64-bit and perhaps ARM Macs.
ttflee 12y ago
IMHO, they want to get everything that has a UI as responsive as possible. GC in theory is a good feature but it does not guarantee that constant time is used for each mark-and-sweep cycle. And together with multithreading that means uncertainty for rendering every frame of video, which is done in the main thread of an App 60 times per second. And for modern system, anything you see on screen is part of this rendering. Try to think about how could memory shared by main thread and a background thread be GCed. It could turn out to be: halting the process for GC, retaining some memory forever, or implementing some complicated algorithm that is too difficult to debug/maintain.
- oconnor0 12y ago
  That can be resolved with a different GC.
  - ttflee 12y ago
    Yes, I have heard of some algorithms that consume a lot more memory to balance timing. E.g.: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
  - fidotron 12y ago
    Not really. I've had to deploy lots of soft real time apps on GCed environments over the years, and it's always a problem. You can work around it with things like object pools, but some library or API will assume that the GC is OK and will be quietly spitting out objects continuously which will lead to a GC pause. It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. Even if you're in C++ modern compilers can only make the most out of it if you pass by value, as this enables all sorts of other optimisations to kick in. The key benefit of reference counting is it's predictable. Real time systems are also not strictly the lowest latency, they are defined by predictability. This becomes a preoccupation with minimising your worst case scenario.
    - krschultz 12y ago
      It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. This is simply not true. The API has always been heavily based on Java primitives. They didn't even use enums in the older APIs, preferring instead int constants. (I hate that one personally). GC pauses have always been a point of focus for the Android platform.
pjmlp 12y ago
GC never worked properly in Objective-C. Apple failed to produce a working GC that didn't crash all the time, because it required all Objective-C libraries to be compiled the same way. Additionally the C subset only allows for conservative GC, which is not optimal when performance matters. So in the end they went with ARC, with isn't nothing more than having the compiler produce the retain/release calls that Mac OS X frameworks were already expecting anyway. So this has more to do with how technically feasible it is to have a proper GC in Objective-C, than GC in general.
bitwize 12y ago
Everything GC can do, ARC can do in strict space and time constraints.
- danbruc 12y ago
  Plain (automatic) reference counting can not handle cycles without support from developers.
  - blub 12y ago
    I find that a good thing, because developers are trained to think that they have to use weak references and think about object lifetimes. Android developers tend to not think so much about lifetimes which leads to memory leaks because Dalvik apparently can't figure out some of those cycles by itself. Just do a search for "Android memory leak" to see some examples.
    - smrtinsert 12y ago
      A platform with 80% of mobile installations has developers who don't understand object lifecycles Got it.
      - kasabali 12y ago
        I guess he meant Android application developers, not the people who wrote Dalvik.
    - tomjen3 12y ago
      Try to parse any tree structure without creating cycles (say the XML/XHTML inside an ebook) - that may be possibly with just one or two devs on the project but as soon as every dev doesn't know every line of code there is an oppertunity for errors and you only need one link to leak memory. That Dalvik can't handle the cycles is stupid but an issue with Dalvik (that is likely to be phased out with the new runtime) not an issue with GC. Computers are really, really, good about executing trivial tasks repeatedly without ever making a stupid mistake, humans not so. And as Terminator taught us: never send a human to do a machines job.

jimrandomh 12y ago

What the fuck? This is a really bad technical decision. As written, it sounds like they're planning to reject garbage collection in-general, which would be a ban on most major programming languages. If you assume they only mean garbage collection in Objective C, it's still a head-scratchingly stupid decision. Modifying an app to not use garbage collection is, in many cases, a major project that will introduce a lot of bugs. And the benefit is... very dubious at best.

wsc981 12y ago
I'm pretty sure this notification is only meant for apps using the Objective-C garbage collector, as the notification mentions that the GC was deprecated a while ago. I don't think a lot of Mac developers used the Objective-C GC anyway. Finally Apple mentions the following in it's migration document [0]: Is GC (Garbage Collection) deprecated on the Mac? Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X. Automatic Reference Counting is the recommended replacement technology. To aid in migrating existing applications, the ARC migration tool in Xcode 4.3 and later supports migration of garbage collected OS X applications to ARC. Based on the above statement, my guess is that's Xcode has some build-in tools to convert GC code to ARC code, making the transition easier. --- [0]: https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/ios/releasenotes/Objecti...
deleted 12y ago
[deleted]
- jimrandomh 12y ago
  Er, what? Transitioning from GC to ARC doesn't make code cleaner or reduce bugs. It eliminates GC pauses, which is a slight speedup, but the set of bugs that a garbage-collected program has are roughly a subset of the bugs that a reference-counted program can have.
tptacek 12y ago
This is not a ban on garbage-collected programming languages.

zbowling 12y ago

To head off some of the misconceptions here, this is not about garbage collection in general but Objective-C built-in garbage collection. Apple NEEDs to do this for their own sanity. I'm surprised they waited this long actually. It's a serious PITA to support GC and non GC at the same time in a framework. Having to add finalizer methods instead of relaying on dealloc methods and dealing with non-deterministic object lifetime as well as deterministic was a huge problem. ARC doesn't have these problems because it wraps traditional manual reference counting (to pick nits, it actually bypasses it when it can safely but this is an optimization detail that you shouldn't need to worry about). To Apple and 3rd party framework developers, it's painful to support GC and non-GC paths in your code at the sametime. It's not really possible to use a non-GC compatible framework in a GC app. It's also impossible to use ARC and still support the GC as well in the same framework. Apple has been completely prevented from using ARC in it's own frameworks because of keeping GC compatible apps working, and making this change will allow them to start ARC-ifying their own code. It also means that a significant chunk of the ObjC runtime can be simplified. There are also some great advancements in the ObjC runtime that Apple is doing (like tagged pointers and shadow objects) that the reference boehm garbage collector can't really deal with and was all completely disabled in the ObjC runtime when you had a GC app. This is a good thing. Not many app actually shipped with the ObjC garbage collector and ran well. Now you are free to use your GC for your own needs in your app. That has nothing to do with ObjC. Feel free to add Java or Ruby or whatever language you like to your own app and submit that to the Mac App Store.

deleted 12y ago
[deleted]
LeoNatan25 12y ago
Question is, are they removing support from the OS frameworks themselves or just Mac App Store? There are many applications that still use GC, many of which are not in the store. Does that mean they cut support for these in a future 10.10 update or 10.11? I doubt it.
- realityking 12y ago
  I'd bet on 10.11 or 10.12. ig they don't eventually remove it, there's little point in deprecating it or forcing it off the App Store as they can not reap the benefits in their own code.

amit_m 12y ago

Does ARC work like reference counting in python? (i.e. a reference count is stored for every object)

cfrs 12y ago
Yes, refcount is stored for every object, but ARC is not able to detect cycles.
- berdario 12y ago
  To help with this, both Python and ObjC have weak references https://docs.python.org/3/library/weakref.html https://docs.python.org/3/library/weakref.html
  - cfrs 12y ago
    AFAIK python have kind of cycles detector enabled by default.
    - berdario 12y ago
      Sort of, CPython has both reference counting and a normal Garbage Collection. You can disable the latter and still avoid memory leaks as long as you don't have cycles
  - dragonwriter 12y ago
    Weak references don't primarily exist to deal with cycles, and cycles generally often involve necessarily strong references even in systems that support weak references. (That is, e.g., cycles where A needs to be reachable if B is reachable and vice versa, such that a weak reference that allowed B to be disposed while A was reachable or vice versa would not be acceptable. A system that can detect cyclic garbage will still be able to collect both A and B -- connected by strong references -- when neither can be reached from the rest of the program.)
    - mst 12y ago

falcolas 12y ago

I wonder how many applications will start leaking memory as a result of this? Cyclic references are not that uncommon in many algorithms, and identifying the need to remove these will be challenging for applications which relied on automatic identification will take time.

jahewson 12y ago
Xcode can help with that, as it says in the "Transitioning to ARC Release Notes": > To aid in migrating existing applications, the ARC migration tool in Xcode 4.3 and later supports migration of garbage collected OS X applications to ARC.
jjoonathan 12y ago
When it comes to overall ease of use, the importance of tooling dwarfs the importance of GC vs RC, and apple has had really solid RC tooling for a while. It graphs memory usage, searches out leaked objects (by injected GC or by diffs), lists them, lists the retain/release events with timestamps, and lets you jump to the responsible code with a single click. Compare that to the nightmare of trying to get a misbehaving GC to cooperate and suddenly it doesn't seem so crazy. EDIT: Or at least they had such tools 5-6 years ago, regression is certainly possible. For unrelated reasons I've been playing in other playgrounds for the last 5-6 years so I can't say for sure.

userbinator 12y ago

I'm not so familiar with the Mac ecosystem, but is it really true that Apple decides what languages you can use to write your apps in?

parasubvert 12y ago
No. You can write it in whatever you want (even on iOS these days) though you can't depend on any third party pre-installations. IOW you need to be able to vendor in your 3rd party language and library dependencies, and use a thin Objective-C wrapper to make the whole thing natively executable. This announcement is more about a feature in Objective-C being actively discouraged by refusing to distribute your app on their store. You can still use it if you distribute your app on your own.
- jimrandomh 12y ago
  > No. You can write it in whatever you want (even on iOS these days) This is somewhat misleading. Apple bans all use of JIT compilation on iOS, which de facto eliminates languages that depend on it.
  - greggman 12y ago
    I thought they just banned the use of code not embedded in your app. You are free to Jit. Just not files downloaded from the net. Only files embedded In your app
    - Ecco 12y ago
      No you can't jit. For a very simple reason: you cannot allocate memory that is both writable and executable.
    - wging 12y ago
      For those who are wondering, you can still use an embedded webview, which does end up doing just-in-time compilation of javascript.

philippnagel 12y ago

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.

jakobegger 12y ago

This is a pity. I have an app that uses ARC on 64bit, and GC on 32bit. Allowed me to ditch manual memory management without dropping support for 32bit machines.

FigBug 12y ago
Is there still demand for 32 bit apps? The last 32-bit mac was released in 2006 and the last OS 32 bit OS in 2009?
- delinka 12y ago
  The most recent version of Microsoft Office for OS X is still 32-bit, still uses the deprecated event system, and still uses deprecated file I/O functions ... Remember resource forks?
  - mglinski 12y ago
    The most recent released version of Office for Mac is also from 2010.
  - FigBug 12y ago
    If I wasn't clear, my question was the opposite, not is there still demand to run 32-bit software, but is there demand for new 32-bit software from people who can't run 64-bit. I've assumed anybody with a almost 10 year old computer doesn't get that much new software. I tend to release supporting the last 2 or 3 OS releases and 64-bit only and haven't received any complaints.
    - delinka 12y ago
      I did indeed misinterpret. To answer that way, I'm not personally aware of anyone demanding new apps targeted to 32-bit on OS X. As an OS X developer, I'm averse to the idea of starting a new app with that as a target.
- jakobegger 12y ago
  I still use my 2006 iMac occasionally, so I care. Macs live a lot longer than phones. However, you are right, there is little demand for 32bit software; my newer apps require 64bit. But I see no reason to cut off support in an old product.

zomgbbq 12y ago

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html https://developer.apple.com/library/ios/documentation/Swift/...

tacos 12y ago

Awesome. Now all they gotta do is stop treating strings like we're in a Pascal Intro to Computer Science class circa 1987 and we gots ourselves a kick ass development environment here. :)

jeffsco 12y ago

What Apple calls "automatic reference counting" is what is usually known as just "reference counting." They call it "automatic" to distinguish it from the previous, even cruder, system where counts were manipulated directly by the programmer. Obviously this is an improvement, but personally I am a supporter of GC. It is a myth that reference counting is not subject to arbitrary pauses: http://www.hboehm.info/gc/myths.ps http://www.hboehm.info/gc/myths.ps

TheLoneWolfling 12y ago
Incorrect. You can, although I haven't seen systems that do this, enqueue objects to be deallocated then have either the main thread every once in a while or a background thread periodically pop objects off of the queue and do the normal reference counting dance.
- mst 12y ago
  This is pretty much what the perl5 VM does on scope exit to blow away unused temporaries. Weak references take a while to figure out but once you have, refcounting is so much more predictable than GC.
- gchpaco 12y ago
  Yup, the problem with this is that it renders the other claimed advantage of reference counting moot (viz. there is now little or no temporal linkage between when the object's ref count hits 0 and when its destructor/finalizer is called). The other problem with reference counting, which is I believe insoluble, is that it is inherently O(alldata); that is to say you must perform an operation each time a piece of memory dies, at the very least. This makes it good for collecting older generations in a generational GC (where O(alldata) ~= O(livedata)) but bad for the nursery (where the generational assumption means that O(livedata) << O(alldata)).
  - TheLoneWolfling 12y ago
    Any computer processor can do a finite number of operations per time period, and an (effectively) arbitrary number of objects can be marked for deallocation simultaneously. So yes, you can have arbitrary delays. But this is always the case. Refcounting, GC, manual memory management, etc. But I'd say you've gone one step too far in saying that there is little or no temporal linkage with refcounting. If you're using a queue, objects will be cleaned up as soon as they can be while remaining inside the time limitations you've allowed. If you want to get fancy, you can even have the compiler rearrange objects such that pointers that are likely to point to objects with destructors are first in line. And yes, refcounting is O(alldata). But that's ignoring that freeing is relatively fast, and that you can easily implement bunches and bunches of optimizations to prevent refcounting from having to work at all.(For example: if you acquire a reference to an object on the same thread and then release it, you don't have to do anything. If you create an object, but at runtime you can determine that you never released the reference to anything, you can free it immediately. If you acquire multiple references to an object, you only need to check for references reaching zero once. Etc. All of these are things that theoretically can be done with a standard GC, but good luck actually doing so.)