4 ms·

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 thi

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.
  - TazeTSchnitzel 12y ago
    Well, deprecating it would mean they're free not to support it in newer frameworks, right?
- ejdyksen 12y ago
  At the very bottom of the documentation page linked from this page [1], it says it will be removed. Sounds pretty definitive to me. 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. [1]: https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/ios/releasenotes/Objecti...
- zbowling 12y ago
  It will stop working in 10.11 entirely.
tomjen3 12y ago
That seems a really good argument for killing manual memory management, not for killing the GC option. As a user I want dev time to be spent adding needed features, not chasing down memory cycles (which _will_ happen when you add something like blocks to a language without garbage collection). As a programmer I don't want to litter my code with disgusting crap that only serves to tell the compiler something it should be able to infer anyway. My suspection is that Apple is just doing it because they don't want to put the necessary RAM in their phones (Android has something like twice the amount of memory Apple has at this point).
- zbowling 12y ago
  That is what ARC is for which is superior to the GC which never really worked properly anyways. ARC is deterministic. The only problem is that doesn't automatically handle retain cycles. ARC is compatible with manual reference counting entirely, but internally, when ARC detects the classes in a particular objects hierarchy are not doing anything fancy with MRC, it's super clever and bypasses it for a bit of a speed boost. It means that the developer doesn't have to do anything extra to be compatible with ARC from MRC or the other way around.
  - tomjen3 12y ago
    >The only problem is that doesn't automatically handle retain cycles. That would be like saying the only problem with the Titanic is that it had a few extra holes in it. Of course what Apple really should do is dump its old tech and more to something new and more modern. I hate to say it but when even Java is more modern and can do stuff your system can't, it is time to upgrade (preferably to something other than Java).
    - zbowling 12y ago
      > Of course what Apple really should do is dump its old tech and more to something new and more modern. They did. It's called Swift... and it uses ARC under the hood as well.

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.
- TazeTSchnitzel 12y ago
  Well, deprecating it would mean they're free not to support it in newer frameworks, right?
ejdyksen 12y ago
At the very bottom of the documentation page linked from this page [1], it says it will be removed. Sounds pretty definitive to me. 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. [1]: https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html https://developer.apple.com/library/ios/releasenotes/Objecti...
zbowling 12y ago
It will stop working in 10.11 entirely.

tomjen3 12y ago

That seems a really good argument for killing manual memory management, not for killing the GC option. As a user I want dev time to be spent adding needed features, not chasing down memory cycles (which _will_ happen when you add something like blocks to a language without garbage collection). As a programmer I don't want to litter my code with disgusting crap that only serves to tell the compiler something it should be able to infer anyway. My suspection is that Apple is just doing it because they don't want to put the necessary RAM in their phones (Android has something like twice the amount of memory Apple has at this point).

zbowling 12y ago
That is what ARC is for which is superior to the GC which never really worked properly anyways. ARC is deterministic. The only problem is that doesn't automatically handle retain cycles. ARC is compatible with manual reference counting entirely, but internally, when ARC detects the classes in a particular objects hierarchy are not doing anything fancy with MRC, it's super clever and bypasses it for a bit of a speed boost. It means that the developer doesn't have to do anything extra to be compatible with ARC from MRC or the other way around.
- tomjen3 12y ago
  >The only problem is that doesn't automatically handle retain cycles. That would be like saying the only problem with the Titanic is that it had a few extra holes in it. Of course what Apple really should do is dump its old tech and more to something new and more modern. I hate to say it but when even Java is more modern and can do stuff your system can't, it is time to upgrade (preferably to something other than Java).
  - zbowling 12y ago
    > Of course what Apple really should do is dump its old tech and more to something new and more modern. They did. It's called Swift... and it uses ARC under the hood as well.