6 ms·

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, a

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

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