4 ms·

> The ObjC runtime is poorly architected, shows its age, and is not sufficiently well designed to permit the implementation of features that would grossly simpl

> The ObjC runtime is poorly architected, shows its age, and is not sufficiently well designed to permit the implementation of features that would grossly simplify the use of the language. The first two points are not defined in a sufficient way that would allow us to have a meaningful conversation about them. What does it mean to be poorly-designed? What does it mean to be old, and why is old bad? We cannot make progress here without semantic introspection. On the third topic, however: > In support of this I mentioned a number of features that simply are non-implementable on the current runtime, including automatic handling of reference cycles I'd like to examine this particular assertion in substantial detail, because it is apparent to me I have not communicated clearly: 1) First of all, the statement "automatic handling of reference cycles is not possible to implement because of the Objective-C runtime" is false. It is false because it has in fact been implemented, in spite of the Objective-C runtime: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#//apple_ref/doc/uid/TP40008006-SW2 https://developer.apple.com/library/mac/#documentation/Cocoa... 2) I've made the general argument that many features are not useful on a 5w computer. Now I will make the specific argument that detecting retain cycles is not useful on a 5w computer: > We have no heap scans, no whole-app pauses, and no non-deterministic releases. We really think that a smooth, fluid interface is important to our customers, and that great battery life is also important. And with that, GC is deprecated. - Apple, WWDC 2012 session 406, about 34 minutes in Now extending this two-case line of reasoning to the general list of features: I do not believe (and you have provided no evidence to support) that the Objective-C runtime is the limiting factor for any feature you have listed. I also do not believe (and you have provided no evidence to support) that any feature is useful on a 5w computer. In this particular most-favored case, both of these problems apply, but I believe at least one problem applies to every feature you have listed. > Somebody should tell Microsoft and the MonoTouch guys. Even Android's GC is usable, and it's an fairly primitive mark-and-sweep collector. I think they already know: > The occurrence of this is non-deterministic, and may happen at inopportune times (e.g. in the middle of graphics rendering). If you see this message, you may want to perform an explicit collection elsewhere, or you may want to try to reduce the lifetime of peer objects. http://docs.xamarin.com/android/advanced_topics/garbage_collection http://docs.xamarin.com/android/advanced_topics/garbage_coll... As I understand it, MonoTouch's optional SGen does a better job, but still uses a stop-the-world algorithm for "large" objects. Given the memory constraints of most iOS devices, lots of things are large relative to the amount of memory you have available. For example, my real-world iPad currently has 90MB in the free pool, which means that a single layer that draws to screen is 10% of the immediately available memory in pure graphics buffer allocations. (It is possible to increase the available pool, and in fact iOS will instruct apps to dump what they can if more is requested, but this is slow and also not being a good memory citizen).

flatline3 14y ago
The ObjC runtime is poorly designed in part due to the fact that it fails to cleanly and adequately represent the necsessary metadata to support new features, and thus requires repeated ABI breakage as Apple stumbles about trying to implement enhancements. As compared to other runtime designs, and as I've noted elsewhere in comparison to the JVM specification, this is a uniquely poor showing for a runtime. To address your claim that the runtime allows for GC because GC was implemented poorly for Mac OS: The previous GC implementation had fatal flaws in performance and execution, required substantial runtime changes, and involved breaking the previous ABI and requiring binaries to declare conformance to a new one. ARC required a lesser amount of runtime changes, but also failed to include basic bookkeeping to support handling of cycles in the future. As for accepting Apple's assertions about GC at face value -- this is the same organization that proudly trumpeted their poor implementation of GC at WWDCs past, and migrated their entire set of Mac OS frameworks to support it. Apple makes serious mistakes and are often proven wrong. GC at Apple died because of a poor implementation, political fallout from it, and lack of adequate investment in it. I find it disturbing and sad that all Apple has to do is state 'GC bad' (for internal Apple political reasons!), and suddenly the masses of Apple developers with no significant experience using GC -- much less implementing it -- are parroting the line. You reference that SGen requires hinting; the fact is, it does work, and the required hinting is nothing compared to dealing with reference cycles in block heavy code. Regardless of that, Apple should be capable of bringing more computer science firepower to this problem than Mono is. Someone else in this thread has already linked to research into hybrid refcount GCs.
- drewcrawford 14y ago
  The way this argument is going is a very eloquent "he said, he said". I'd like to push it into a better discussion. Could you drop the rhetoric about "parroting the WWDC line" and "Apple stumbling about", the ad-hominem characterizations of developers who haven't implemented a GC, etc.? I'm going to require you to provide hard facts or examples to support your claims, and not present conclusions as arguments, and not muddy the waters. > The ObjC runtime is poorly designed in part due to the fact that it fails to cleanly and adequately represent the necsessary metadata to support new features, and thus requires repeated ABI breakage as Apple stumbles about trying to implement enhancements. The ABI was "changed" once. When I say it was "changed", I really mean that the new ABI was released for the first time on new architectures that did not previously have an ABI at all, and the old architectures' ABI did not change. Assuming that your objection to ABI "breakage" was compatibility-based in nature, this objection would be unfounded. You have also failed to make a claim that any particular feature is both useful and unimplementable, and also failed to support such a claim. Please make and support claims, not conclusions. > As for accepting Apple's assertions about GC at face value -- this is the same organization that proudly trumpeted their poor implementation of GC at WWDCs past, and migrated their entire set of Mac OS frameworks to support it. To be fair, garbage collection was released before iOS was released. Apple's position is today, and has always been, that garbage collection is infeasible on iOS. What has changed between 2006 and 2012 is that it now makes a lot of sense from both a developer mindshare point of view and an Apple engineer cost/benefit point of view to make Mac OS be as close to iOS as possible, because that's where the money is. There are very good reasons why (e.g. non-deterministic finalization) it is impossible to share code and illogical to share engineers between ARC and GC codebases. > GC at Apple died because of a poor implementation, political fallout from it, and lack of adequate investment in it. This contradiction is baseless (e.g. unsupported), so on that basis I am not compelled to respond. It also contradicts my discussions with engineers who were involved in the decision, so if you were to provide a basis, I have first-hand accounts with which to refute you. > Regardless of that, Apple should be capable of bringing more computer science firepower to this problem than Mono is. And here is the fundamental disconnect: you believe that currently-known GC algorithms are "good enough" for general use on iOS. I do not. Apple does not. Thinking it through logically, there are three possible root causes for this disagreement: 1. You and I could have a different conception of the hardware capabilities of iOS devices 2. You and I could have a different conception of the performance characteristics for currently-known GC algorithms 3. You and I could have a different threshold for user pain, so you might characterize a certain performance penalty as "acceptable" that I would characterize as "unacceptable." We've danced a little bit around #1 and #2, and we can talk some more about those. But I think the real issue might be #3. For example, the native screen refresh rate is 60fps. I would consider it unacceptable to skip five consecutive frames, and unacceptable to skip more than 15 frames as a sustained average over many seconds. Mono documents "major collections" to take a second, which fails both criteria. [1] I would also consider it unacceptable that, upon returning to the run loop (or equivalent common synchronization point), more than 15% of garbage bytes remain uncollected. There's just not that much memory to go around. At this point, I have laid out in very specific detail what I mean by "performs acceptably". Now, you can either A) tell me that my demands are insane, in which case we simply have a very different idea of what "responsive user interface" means, and there's really nothing more to be said to convince the other. Or, B) demonstrate that there exists some GC implementation which fulfills these requirements, and additionally demonstrate that it cannot be implemented with the current ObjC runtime. I think this is the the healthiest way forward for the discussion, because it leaves open the possibility that we may learn something. If instead we return to the things I listed in the first paragraph, I think we both have better uses of our time. [1] http://android.xamarin.com/index.php?title=Documentation/GC http://android.xamarin.com/index.php?title=Documentation/GC

flatline3 14y ago

The ObjC runtime is poorly designed in part due to the fact that it fails to cleanly and adequately represent the necsessary metadata to support new features, and thus requires repeated ABI breakage as Apple stumbles about trying to implement enhancements. As compared to other runtime designs, and as I've noted elsewhere in comparison to the JVM specification, this is a uniquely poor showing for a runtime. To address your claim that the runtime allows for GC because GC was implemented poorly for Mac OS: The previous GC implementation had fatal flaws in performance and execution, required substantial runtime changes, and involved breaking the previous ABI and requiring binaries to declare conformance to a new one. ARC required a lesser amount of runtime changes, but also failed to include basic bookkeeping to support handling of cycles in the future. As for accepting Apple's assertions about GC at face value -- this is the same organization that proudly trumpeted their poor implementation of GC at WWDCs past, and migrated their entire set of Mac OS frameworks to support it. Apple makes serious mistakes and are often proven wrong. GC at Apple died because of a poor implementation, political fallout from it, and lack of adequate investment in it. I find it disturbing and sad that all Apple has to do is state 'GC bad' (for internal Apple political reasons!), and suddenly the masses of Apple developers with no significant experience using GC -- much less implementing it -- are parroting the line. You reference that SGen requires hinting; the fact is, it does work, and the required hinting is nothing compared to dealing with reference cycles in block heavy code. Regardless of that, Apple should be capable of bringing more computer science firepower to this problem than Mono is. Someone else in this thread has already linked to research into hybrid refcount GCs.

drewcrawford 14y ago
The way this argument is going is a very eloquent "he said, he said". I'd like to push it into a better discussion. Could you drop the rhetoric about "parroting the WWDC line" and "Apple stumbling about", the ad-hominem characterizations of developers who haven't implemented a GC, etc.? I'm going to require you to provide hard facts or examples to support your claims, and not present conclusions as arguments, and not muddy the waters. > The ObjC runtime is poorly designed in part due to the fact that it fails to cleanly and adequately represent the necsessary metadata to support new features, and thus requires repeated ABI breakage as Apple stumbles about trying to implement enhancements. The ABI was "changed" once. When I say it was "changed", I really mean that the new ABI was released for the first time on new architectures that did not previously have an ABI at all, and the old architectures' ABI did not change. Assuming that your objection to ABI "breakage" was compatibility-based in nature, this objection would be unfounded. You have also failed to make a claim that any particular feature is both useful and unimplementable, and also failed to support such a claim. Please make and support claims, not conclusions. > As for accepting Apple's assertions about GC at face value -- this is the same organization that proudly trumpeted their poor implementation of GC at WWDCs past, and migrated their entire set of Mac OS frameworks to support it. To be fair, garbage collection was released before iOS was released. Apple's position is today, and has always been, that garbage collection is infeasible on iOS. What has changed between 2006 and 2012 is that it now makes a lot of sense from both a developer mindshare point of view and an Apple engineer cost/benefit point of view to make Mac OS be as close to iOS as possible, because that's where the money is. There are very good reasons why (e.g. non-deterministic finalization) it is impossible to share code and illogical to share engineers between ARC and GC codebases. > GC at Apple died because of a poor implementation, political fallout from it, and lack of adequate investment in it. This contradiction is baseless (e.g. unsupported), so on that basis I am not compelled to respond. It also contradicts my discussions with engineers who were involved in the decision, so if you were to provide a basis, I have first-hand accounts with which to refute you. > Regardless of that, Apple should be capable of bringing more computer science firepower to this problem than Mono is. And here is the fundamental disconnect: you believe that currently-known GC algorithms are "good enough" for general use on iOS. I do not. Apple does not. Thinking it through logically, there are three possible root causes for this disagreement: 1. You and I could have a different conception of the hardware capabilities of iOS devices 2. You and I could have a different conception of the performance characteristics for currently-known GC algorithms 3. You and I could have a different threshold for user pain, so you might characterize a certain performance penalty as "acceptable" that I would characterize as "unacceptable." We've danced a little bit around #1 and #2, and we can talk some more about those. But I think the real issue might be #3. For example, the native screen refresh rate is 60fps. I would consider it unacceptable to skip five consecutive frames, and unacceptable to skip more than 15 frames as a sustained average over many seconds. Mono documents "major collections" to take a second, which fails both criteria. [1] I would also consider it unacceptable that, upon returning to the run loop (or equivalent common synchronization point), more than 15% of garbage bytes remain uncollected. There's just not that much memory to go around. At this point, I have laid out in very specific detail what I mean by "performs acceptably". Now, you can either A) tell me that my demands are insane, in which case we simply have a very different idea of what "responsive user interface" means, and there's really nothing more to be said to convince the other. Or, B) demonstrate that there exists some GC implementation which fulfills these requirements, and additionally demonstrate that it cannot be implemented with the current ObjC runtime. I think this is the the healthiest way forward for the discussion, because it leaves open the possibility that we may learn something. If instead we return to the things I listed in the first paragraph, I think we both have better uses of our time. [1] http://android.xamarin.com/index.php?title=Documentation/GC http://android.xamarin.com/index.php?title=Documentation/GC