6 ms·

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 lo

by 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.

by danbruc 12y ago

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.