www.digitalmars.com         C & C++   DMDScript  

D - Program destructor/deletion

reply Burton Radons <loth users.sourceforge.net> writes:
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.
Jun 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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>.
Jun 05 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"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

 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.
Jun 05 2003
prev sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
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
Jun 06 2003
parent "Walter" <walter digitalmars.com> writes:
"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
Aug 01 2003