More radical ideas about gc and reference counting

[Xavier Bigand via Digitalmars-d]

Le 06/05/2014 12:58, Manu via Digitalmars-d a écrit :
> 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.
>
+1

D seems to mainly interests C++ developers that generally aren't 
interested by dynamically types language and based on a GC.
But we always have the possibility to link C++ to a higher language for 
some part of applications.
IMO system languages have to continue working with manual memory management.