The "no gc" crowd

PauloPinto pjmlp at progtools.org
Wed Oct 9 00:31:45 PDT 2013


On Wednesday, 9 October 2013 at 06:05:52 UTC, dennis luehring 
wrote:
> Am 09.10.2013 07:23, schrieb PauloPinto:
>> Apple dropped the GC and went ARC instead, because they never
>> managed to make it work properly.
>>
>> It was full of corner cases, and the application could crash if
>> those cases were not fully taken care of.
>>
>> Or course the PR message is "We dropped GC because ARC is 
>> better"
>> and not "We dropped GC because we failed".
>>
>> Now having said this, of course D needs a better GC as the
>> current one doesn't fulfill the needs of potential users of the
>> language.
>
> the question is - could ARC be an option for automatic memory 
> managment
> in D - so that the compiler generated ARC code when not using 
> gc - but using gc-needed code?
>
> or is that a hard to reach goal due to gc-using+arc-using lib 
> combine problems?

Personally I think ARC can only work properly if it is handled by 
the compiler, even if D is powerful enough to have them as 
library types.

ARC is too costly to have it increment/decrement counters in 
every pointer access, in time and cache misses.

Objective-C, Rust and ParaSail do it well, because ARC is built 
into the compiler, which can elide needless operations.

Library solutions like C++ and D suffer without compiler support.

Personally, I think it could be two step:

- Improve the GC, because it what most developers will care about 
anyway

- Make the D compilers aware of RefCounted and friends, to 
minimize memory accesses, for the developers that care about 
every ms they can extract from the hardware.


--
Paulo


More information about the Digitalmars-d mailing list