Getting completely (I mean ENTIRELY) rid off GC

[Chris via Digitalmars-d]

On Friday, 12 September 2014 at 12:39:51 UTC, Paulo  Pinto wrote:
> On Friday, 12 September 2014 at 07:46:03 UTC, eles wrote:
>> On Thursday, 11 September 2014 at 19:56:17 UTC, Paulo Pinto 
>> wrote:
>>> Am 11.09.2014 20:32, schrieb Daniel Alves:
>>
>>> It is incredible how Objective-C's ARC became a symbol for 
>>> reference counting, instead of the living proof of Apple's 
>>> failure to produce
>>> a working GC for Objective-C that didn't crash every couple 
>>> of seconds.
>>
>> I think I fail to grasp something here. For me, ARC is 
>> something that is managed at runtime: you have a counter on a 
>> chunk of memory and you increase it with each new reference 
>> towards that memory, then you decrement it when memory is 
>> released. In the end, when the counter reaches 0, you drop the 
>> chunk.
>>
>> OTOH, code analysis and automatically inserting free/delete 
>> where the programmers would/should have done it is not really 
>> that. Is a compile-time approach and not different of manual 
>> memory management.
>>
>> Which one is, in the end, the approach took by Apple, and 
>> which one is the "true" ARC?...
>
> ARC was a term popularized by Apple when they introduced the 
> said feature in Objective-C.
>
> In the GC literature it is plain reference counting.
>
> ARC in Objective-C is a mix of both approaches that you mention.
>
> It only applies to Objective-C classes that follow the 
> retain/release patterns since the NeXTStep days. For structs, 
> malloc() or even classes that don't follow the Cooca patterns, 
> only manual memory management is possible.
>
> The compiler inserts the retain/release calls that a programmer 
> would write manually, at the locations one would expect from 
> the said patterns.
>
> Then a second pass, via dataflow analysis, removes the pairs of 
> retain/release that are superfluous, due to object lifetime 
> inside a method/function block.
>
> This way you get automatic reference counting, as long as those 
> classes use the said patterns correctly. As a plus the code 
> gets to interact with libraries that are clueless about ARC.
>
> Now, having said this, when Apple introduced GC in Objective-C 
> it was very fragile, only worked with Objective-C classes, was 
> full of "take care of X when you do Y" and required all 
> Frameworks on the project to have compatible build settings.
>
> Of course, more often than not, the result was random crashes 
> when using third party libraries, that Apple never sorted out.
>
> So ARC in Objective-C ended up being a better solution, due to 
> interoperability issues, and not just because RC is better than 
> GC.
>
> --
> Paulo

[Caveat: I'm no expert]
I once read a manual that explained the GC in Objective-C (years 
ago). It said that some objects never get collected although 
they're dead, but the garbage collector can no longer reach them. 
But maybe that's true of other GC implementations too (Java?). 
ARC definitely makes more sense for Objective-C than what they 
had before. But that's for Objective-C with its retain-release 
mechanism. Also, I wonder, is ARC really "automatic". Sure, the 
compiler inserts retain-release automatically (what the 
programmer would have done manually in the "old days"). But 
that's not really a GC algorithm that scans and collects during 
runtime. Isn't it cheating? Also, does anyone know what problems 
Apple programmers have encountered with ARC?