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