On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d <digitalmars-d@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.