More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 06/05/14 08:07, HaraldZealot wrote:
>
>> I notice that I view only part of problem, can anybody link or describe
>> me completely state and problems of current garbage collection and other
>> resource management? It help me in finding of existence solution (at
>> least theoretical).
>
>
> The major issue with the garbage collector is that it's not guaranteed to
> run a collection. When a collection is run the GC will call the destructors
> for the objects it collects. If there's no guarantee a collection is run
> there can be no guarantee that destructors are called. A collection is
> usually run when allocating new memory and there's not enough memory
> available.

I think it's also an important consideration that GC is incompatible
with low-memory and real-time environments.

The trouble is, GC runs more frequently as the amount of available
free memory decreases, and trace&collect takes a long time, long
enough that realtime software typically can't tolerate the pause. If
the pause is super rare (minutes/hours apart), maybe it's acceptable,
but if it's closer to every call to alloc (ie, when there is little/no
free memory), then you realise it's fundamentally incompatible.
Then consider that this is typically the default operating state of
embedded systems; to have no free memory at runtime, and therefore D
is effectively incompatible with a subset of computers...
specifically, games consoles; a gigantic industry, and one of the few
that still absolutely relies on native code where D is particularly
compelling.

If people want to call D a native systems language, this seems like a
serious conflict with that idea. A major subset of the language is
incompatible with realtime or embedded use (surely among the most
compelling use cases remaining for native code these days!). Usually
the argument is that I represent a niche, and therefore I should
accept the restrictions of my environment, and revert to full manual
memory management for my work, while letting everyone else have their
fun.
That is a broken argument, not only because it leaves very little
motivation to leave C++, but also because regardless of whether I
adopt such restrictions, library authors won't, and we don't live in
the 1980's where I can write a few lines of self-contained assembly
and call it a program. To say I can't depend on libraries is
practically absurd. Games are gigantic software projects, and depend
on heaps of libraries.

The GC effectively eliminates libraries from embedded/realtime users,
which I see as an absolute deal-breaker alone, irrespective of a
further bunch more restrictions it places on that subset of users
within their own code :/

I'll be happy with any solution that works, really. But as I see it,
reference counting is the only garbage collection technology I know
which will reliably clean up eagerly as things fall out of scope (also
addressing this issue with destructors as bonus), and as such, it
seems the logical solution. ARC is a demonstrable success in Obj-C,
and works well in realtime and embedded systems. D has type system
improvements which would theoretically allow for significant
improvements over Obj-C.