More radical ideas about gc and reference counting

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sat May 10 21:21:13 PDT 2014


On 11 May 2014 03:54, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/10/14, 10:03 AM, Manu via Digitalmars-d wrote:
>>
>> There is a black/white distinction though.
>> It you can't make the freezing go away, it is _incompatible_ with
>> certain classes of software.
>> I don't care what the performance difference is when this is the case.
>> If one option is incompatible and the other is not, then there is no
>> tradeoff.
>
>
> Of course it would be nice to have better support for reference counting. My
> understanding is that you advocate that reference counting would be
> compulsive, which would preclude the GC option.

As I've said many times, I'm really not married to ARC... it just
makes sense. In the years I've been hanging around here, I'm yet to
see anyone present a realistic path for D towards an acceptable GC
solution.
If anybody can do that, I'll reconsider my position. But it seems it's
becoming less and less likely to me.

What I know is that there is a solution which has a proven and
extremely successful track record in native languages and
embedded/realtime systems, and even solves ancillary problems like
destructors while at it. But most importantly, it doesn't exclude any
classes of software by nature.

If ARC were a foundation for D, I wonder if there's opportunity for
programs that may elect to disable the RC and leave the work
exclusively to the backing cycle collector, in the same way that I
might disable the cycle collector and take manual responsibility for
weak references...?

I may argue from a biased perspective, but placing more weight on some
particular negative qualities of a technology is not unreasonable when
they represent a showstopper. Which part of my issue with the GC is
factually incorrect? All it would take is for anyone competent to tell
me how a magic GC (which is compatible with D) will stop freezing in
the low/no-memory environment, and I'll shut up.
Even controlling it... I was initially wishing for something like an
incremental garbage collector, which I could allocate a maximum
periodic time-slice (1ms or less) on a regular basis. Not only was it
agreed that this is basically impossible (a bunch of collection
ground-work would need to be repeated at the start of each
micro-collect, probably representing more time than the total
time-slice... iirc), but it almost certainly loses any raw performance
advantage over ARC in such a case anyway, and it becomes moot.


More information about the Digitalmars-d mailing list