The current way the program ending and garbage collection works is to sequentially destruct and delete objects in a single pass.  This deeply compromises what you can do in destructors, because most pointers are going to be broken.  I would like it if these steps were made separate; first call destructors on objects being deleted, and then free the data.

Moreover, nested destruction of this and manual types should also use separate passes; immediately destruct the object, and free them when the top destructor in this thread exits.

This would make destruction much more predictable and I could do such things as deregistering the object from a static associative array without having to worry about whether that array has been destroyed.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bbojsc$umc$1@digitaldaemon.com...
> The current way the program ending and garbage collection works is to sequentially destruct and delete objects in a single pass.  This deeply compromises what you can do in destructors, because most pointers are going to be broken.  I would like it if these steps were made separate; first call destructors on objects being deleted, and then free the data.
>
> Moreover, nested destruction of this and manual types should also use separate passes; immediately destruct the object, and free them when the top destructor in this thread exits.
>
> This would make destruction much more predictable and I could do such things as deregistering the object from a static associative array without having to worry about whether that array has been destroyed.

There are various ways to do this, I just picked the simplest one. There are other issues, like what if a destructor "reanimates" a dead object, allocates more storage, etc. It's a minefield of potential problems that certainly deserves more thought than I've given it. In the meantime, it's probably best to stick to simple destructors <g>.

"Walter" <walter@digitalmars.com> wrote in message news:bbp1lo$1ajc$1@digitaldaemon.com...
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bbojsc$umc$1@digitaldaemon.com...
> > The current way the program ending and garbage collection works is to sequentially destruct and delete objects in a single pass.  This deeply compromises what you can do in destructors, because most pointers are going to be broken.  I would like it if these steps were made separate; first call destructors on objects being deleted, and then free the data.
> >
> > Moreover, nested destruction of this and manual types should also use separate passes; immediately destruct the object, and free them when the top destructor in this thread exits.
> >
> > This would make destruction much more predictable and I could do such things as deregistering the object from a static associative array without having to worry about whether that array has been destroyed.
>
> There are various ways to do this, I just picked the simplest one. There
are
> other issues, like what if a destructor "reanimates" a dead object, allocates more storage, etc. It's a minefield of potential problems that certainly deserves more thought than I've given it. In the meantime, it's probably best to stick to simple destructors <g>.
>
>

Agree that this a vastly complex area, but I would think providing Burton's first idea of separating dtor calls and memory collection would be a simple and worthwhile first step. It's pretty easy to resist the temptation to allocate memory (even indirectly) in dtors.

Walter wrote:
> 
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bbojsc$umc$1@digitaldaemon.com...
> > The current way the program ending and garbage collection works is to sequentially destruct and delete objects in a single pass.  This deeply compromises what you can do in destructors, because most pointers are going to be broken.  I would like it if these steps were made separate; first call destructors on objects being deleted, and then free the data.
> >
> > Moreover, nested destruction of this and manual types should also use separate passes; immediately destruct the object, and free them when the top destructor in this thread exits.
> >
> > This would make destruction much more predictable and I could do such things as deregistering the object from a static associative array without having to worry about whether that array has been destroyed.
> 
> There are various ways to do this, I just picked the simplest one. There are other issues, like what if a destructor "reanimates" a dead object, allocates more storage, etc. It's a minefield of potential problems that certainly deserves more thought than I've given it. In the meantime, it's probably best to stick to simple destructors <g>.

I remember the problem with GCing one single large array, where it took seconds to end the program. It is efficient in C that you don't have to free all objects at program end. To be equally eficient D should - at program end - only finalize the necessary objects and not free them.

I think it would pay to reconsider the whole GC process because it is
the centerstone on which a lot of other design considerations (e. g.
slices and bit slices) atre layered. For this I think the following
items would be helpful:
   - a minimum description of the current GC system
   - a pluggable architecture that would allow to replace the current
     GC by experimental ones to test their behaviour

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EE04047.E6602780@hls.via.at...
> I think it would pay to reconsider the whole GC process because it is
> the centerstone on which a lot of other design considerations (e. g.
> slices and bit slices) atre layered. For this I think the following
> items would be helpful:
>    - a minimum description of the current GC system
>    - a pluggable architecture that would allow to replace the current
>      GC by experimental ones to test their behaviour

It is pluggable already. The interface to it is minimal, in \dmd\src\phobos\gc.d