More radical ideas about gc and reference counting

[HaraldZealot via Digitalmars-d]

>
> 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.

So it seems that I have understood more than I've thought.

If really problem rely on this than an idea came to my mind 
yesterday. What about separate destructors call and garbage 
collections mechanism? This idea reflects current D state with 
postblit constructor in structures. Raw memory allocation, 
default initialization (with T.init field) and after all that 
calling constructor (especially postblit). In therms of 
destructors it sound as: after becoming object or structure  
needless some automatic mechanism call cascading destructor, but 
memory still not fried, and GC collects memory in its time. Yes 
it's sounded monstrous, but perhaps when which mechanism will 
done only self work, each of them can be lighter. And you always 
can call some kind of finalizator manually for performance (some 
kind of flag can exist to protect from double call of 
destructors).