• Burton Radons (11/11) Jun 05 2003 The current way the program ending and garbage collection works is to
• Walter (7/18) Jun 05 2003 There are various ways to do this, I just picked the simplest one. There...
• Matthew Wilson (7/27) Jun 05 2003 are
• Helmut Leitner (15/37) Jun 06 2003 I remember the problem with GCing one single large array, where it took
• Walter (4/11) Aug 01 2003 It is pluggable already. The interface to it is minimal, in

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.

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

"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

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.

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

"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