www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lazy destruction

reply Arcane Jill <Arcane_member pathlink.com> writes:
In what circumstances is the destructor of a non-auto class called?

Arcane Jill
Jun 08 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca5h0j$5eg$1 digitaldaemon.com...

 In what circumstances is the destructor of a non-auto class called?


1) When 'delete' is called on it.
2) When the garbage collecter collects it.
3) Never.
Jun 08 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca5kd4$a6g$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca5h0j$5eg$1 digitaldaemon.com...

 In what circumstances is the destructor of a non-auto class called?


1) When 'delete' is called on it.
2) When the garbage collecter collects it.
3) Never.


Not (2). You yourself have told me in the past that when the garbage collector
collects the object, it may choose not to execute the destructor. So perhaps my
question should have been, IF the garbage collector sees that a non-auto class
is unreachable, in what circumstances will it CHOOSE to run the destructor?

Sorry for not being clear.

I want to know the circumstance in which a destructor is run, because I want to
ENGINEER those circumstances - to create a class for which the garbage collect
WILL run the destructor. Is that possible?

Jill
Jun 08 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca5l1a$b20$1 digitaldaemon.com>, Arcane Jill says...

I want to know the circumstance in which a destructor is run, because I want to
ENGINEER those circumstances - to create a class for which the garbage collect
WILL run the destructor. Is that possible?


That should of course have read "...to create a NON-AUTO class for which..."

Jill
Jun 08 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
On Wed, 9 Jun 2004 00:18:50 +0000 (UTC), Arcane Jill
<Arcane_member pathlink.com> wrote:


In article <ca5kd4$a6g$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca5h0j$5eg$1 digitaldaemon.com...

 In what circumstances is the destructor of a non-auto class called?


1) When 'delete' is called on it.
2) When the garbage collecter collects it.
3) Never.


Not (2). You yourself have told me in the past that when the garbage collector
collects the object, it may choose not to execute the destructor. So perhaps my
question should have been, IF the garbage collector sees that a non-auto class
is unreachable, in what circumstances will it CHOOSE to run the destructor?

Sorry for not being clear.

I want to know the circumstance in which a destructor is run, because I want to
ENGINEER those circumstances - to create a class for which the garbage collect
WILL run the destructor. Is that possible?

Jill


In the Java world finalizers have a bad reputation:
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
but I think that's because you can't run finalizers by hand like you
can in D. As a result Java finalizers shouldn't do anything important
because you can't rely on them. In D I think it is perfectly ok to
have the destructor do something important as long as the
documentation for the class is very explicit that instances need to be
deleted explicitly otherwise "something important" might not happen,
ever.

D users are smart enough to do the right thing. Or you could just make
the class auto if forgetting a delete or two would be so catastrophic.

-Ben
Jun 08 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca5l1a$b20$1 digitaldaemon.com...

 In article <ca5kd4$a6g$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca5h0j$5eg$1 digitaldaemon.com...

 In what circumstances is the destructor of a non-auto class called?


1) When 'delete' is called on it.
2) When the garbage collecter collects it.
3) Never.


 Not (2). You yourself have told me in the past that when the garbage


collector

 collects the object, it may choose not to execute the destructor.


I must have misspoke, because when the gc collects an object, it *does* run
the destructor.


 So perhaps my
 question should have been, IF the garbage collector sees that a non-auto


class

 is unreachable, in what circumstances will it CHOOSE to run the


destructor?

 Sorry for not being clear.

 I want to know the circumstance in which a destructor is run, because I


want to

 ENGINEER those circumstances - to create a class for which the garbage


collect

 WILL run the destructor. Is that possible?


Yes, that is how it works now.


 Jill
Jun 08 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca5s60$l06$1 digitaldaemon.com>, Walter says...


 Not (2). You yourself have told me in the past that when the garbage


collector

 collects the object, it may choose not to execute the destructor.


I must have misspoke, because when the gc collects an object, it *does* run
the destructor.


How curious. In your post
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:


There's still another problem, though. D's GC does not *guarantee* that
destructors will get run for non-auto objects. Therefore, you might want to
keep a list of all the secure arrays created that haven't been wiped yet,
then on program close with a module destructor, go through the list and 
wipe any remaining ones.


Now, I believe you Walter. You wrote the compiler, and I believe you. But, I
think these two statements are in contradiction, and now I don't know which one
to believe.

Jill
Jun 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca6ego$1fmt$1 digitaldaemon.com...

 In article <ca5s60$l06$1 digitaldaemon.com>, Walter says...


 Not (2). You yourself have told me in the past that when the garbage


collector

 collects the object, it may choose not to execute the destructor.


I must have misspoke, because when the gc collects an object, it *does*




run

the destructor.


 How curious. In your post
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:


There's still another problem, though. D's GC does not *guarantee* that
destructors will get run for non-auto objects. Therefore, you might want




to

keep a list of all the secure arrays created that haven't been wiped yet,
then on program close with a module destructor, go through the list and
wipe any remaining ones.


 Now, I believe you Walter. You wrote the compiler, and I believe you. But,


I

 think these two statements are in contradiction, and now I don't know


which one

 to believe.


What isn't guaranteed is the object being collected. If it *is* collected,
the destructor will be run.
Jun 09 2004
next sibling parent reply hellcatv hotmail.com writes:
why not run the destructors all dead objects at the end (in the atexit)?
that should solve the problem, no?


In article <ca6g6p$1il6$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca6ego$1fmt$1 digitaldaemon.com...

 In article <ca5s60$l06$1 digitaldaemon.com>, Walter says...


 Not (2). You yourself have told me in the past that when the garbage


collector

 collects the object, it may choose not to execute the destructor.


I must have misspoke, because when the gc collects an object, it *does*




run

the destructor.


 How curious. In your post
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:


There's still another problem, though. D's GC does not *guarantee* that
destructors will get run for non-auto objects. Therefore, you might want




to

keep a list of all the secure arrays created that haven't been wiped yet,
then on program close with a module destructor, go through the list and
wipe any remaining ones.


 Now, I believe you Walter. You wrote the compiler, and I believe you. But,


I

 think these two statements are in contradiction, and now I don't know


which one

 to believe.


What isn't guaranteed is the object being collected. If it *is* collected,
the destructor will be run.
Jun 09 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
hellcatv hotmail.com wrote:


why not run the destructors all dead objects at the end (in the atexit)?
that should solve the problem, no?
  


Good idea but some programs never end.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent reply hellcatv hotmail.com writes:
couldn't the garbage collector have something like

gc.force_collect()

not guaranteed to be real time...but it would go through and collect *everything
* possible and run destructors on all.

In article <ca6mm5$1rbi$1 digitaldaemon.com>, J Anderson says...

hellcatv hotmail.com wrote:


why not run the destructors all dead objects at the end (in the atexit)?
that should solve the problem, no?
  


Good idea but some programs never end.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
hellcatv hotmail.com wrote:


couldn't the garbage collector have something like

gc.force_collect()

not guaranteed to be real time...but it would go through and collect *everything
* possible and run destructors on all.
  


There is a fullcollect().  Personally I would like some more options 
with the gc, like some collections that return after a guaranteed amount 
of time.


In article <ca6mm5$1rbi$1 digitaldaemon.com>, J Anderson says...
  


hellcatv hotmail.com wrote:

    


why not run the destructors all dead objects at the end (in the atexit)?
that should solve the problem, no?
 

      


Good idea but some programs never end.

-- 
-Anderson: http://badmama.com.au/~anderson/
    



  



-- 
-Anderson: http://badmama.com.au/~anderson/
Jun 09 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
hellcatv hotmail.com wrote:


 why not run the destructors all dead objects at the end (in the atexit)?
 that should solve the problem, no?


in a convervative collector the GC might mistakely think an object is still
alive even at exit. See the explanation in the link I posted before:
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
Once the GC decides an object is dead it runs the destructor. It's deciding
what is dead that is hard.


 In article <ca6g6p$1il6$1 digitaldaemon.com>, Walter says...

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca6ego$1fmt$1 digitaldaemon.com...

 In article <ca5s60$l06$1 digitaldaemon.com>, Walter says...


 Not (2). You yourself have told me in the past that when the garbage


collector

 collects the object, it may choose not to execute the destructor.


I must have misspoke, because when the gc collects an object, it *does*




run

the destructor.


 How curious. In your post
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:


There's still another problem, though. D's GC does not *guarantee* that
destructors will get run for non-auto objects. Therefore, you might
want




to

keep a list of all the secure arrays created that haven't been wiped
yet, then on program close with a module destructor, go through the
list and wipe any remaining ones.


 Now, I believe you Walter. You wrote the compiler, and I believe you.
 But,


I

 think these two statements are in contradiction, and now I don't know


which one

 to believe.


What isn't guaranteed is the object being collected. If it *is* collected,
the destructor will be run.
Jun 09 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Ben Hinkle wrote:


 hellcatv hotmail.com wrote:
 

 why not run the destructors all dead objects at the end (in the atexit)?
 that should solve the problem, no?


 
 in a convervative collector the GC might mistakely think an object is
 still alive even at exit. See the explanation in the link I posted before:


http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html

 Once the GC decides an object is dead it runs the destructor. It's
 deciding what is dead that is hard.


I think the idea behind the proposal was: at program exit, *every* object
can be considered dead. If that final run of the gc is the very last thing
the program does, you know for sure that none of the objects will ever be
accessed any more.
Jun 09 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
Norbert Nemec wrote:


 Ben Hinkle wrote:
 

 hellcatv hotmail.com wrote:
 

 why not run the destructors all dead objects at the end (in the atexit)?
 that should solve the problem, no?


 
 in a convervative collector the GC might mistakely think an object is
 still alive even at exit. See the explanation in the link I posted
 before:




http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html

 Once the GC decides an object is dead it runs the destructor. It's
 deciding what is dead that is hard.


 
 I think the idea behind the proposal was: at program exit, *every* object
 can be considered dead. If that final run of the gc is the very last thing
 the program does, you know for sure that none of the objects will ever be
 accessed any more.


The static data still needs to be scanned for roots even at exit:

Object please_dont_collect_me_first;
class A {
  ...
  ~this(){ please_dont_collect_me_first.print(); }
  ...
}

might seg-v if the static object is collected at exit before A is collected.
So it has to be considered "alive" when A's destructor runs. So it has to
always be considered "alive" even at exit.

Using module destructors might help here, but I haven't thought about it.
Jun 09 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
<hellcatv hotmail.com> wrote in message
news:ca6kbl$1of7$1 digitaldaemon.com...

 why not run the destructors all dead objects at the end (in the atexit)?
 that should solve the problem, no?


Sometimes people don't want to do this for performance reasons. Also, it's
rather pointless for cleaning up resources, since the OS will already clean
up any resources held by an exiting program.
Jun 09 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribió en el mensaje
news:ca7led$99n$1 digitaldaemon.com
| <hellcatv hotmail.com> wrote in message
| news:ca6kbl$1of7$1 digitaldaemon.com...
|| why not run the destructors all dead objects at the end (in the atexit)?
|| that should solve the problem, no?
|
| Sometimes people don't want to do this for performance reasons. Also, it's
| rather pointless for cleaning up resources, since the OS will already
clean
| up any resources held by an exiting program.

Correct me if I'm wrong, but I recall once reading that Windows 98 (and any
9x, I suppose) didn't correctly clean up memory. And that might be true
considering how bad my work's computer performs after opening and closing
many applications, which doesn't happen in my home's XP.

-----------------------
Carlos Santander Bernal
Jun 09 2004
parent Sean Kelly <sean f4.ca> writes:
In article <ca8292$tas$1 digitaldaemon.com>, Carlos Santander B. says...

Correct me if I'm wrong, but I recall once reading that Windows 98 (and any
9x, I suppose) didn't correctly clean up memory. And that might be true
considering how bad my work's computer performs after opening and closing
many applications, which doesn't happen in my home's XP.


The home versions of windows before XP basically didn't do any resource
management.  Memory fragmentation and the like were extremely common.  But I'm
not sure how far this extended where normal application termination is
concerned.

Sean
Jun 09 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ca6g6p$1il6$1 digitaldaemon.com>, Walter says...

What isn't guaranteed is the object being collected. If it *is* collected,
the destructor will be run.


New questions then.

In what circumstances will the object be collected?
In what circumstances will the object not be collected?

Arcane Jill
Jun 09 2004
parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ca6ro6$22tt$1 digitaldaemon.com...

 In article <ca6g6p$1il6$1 digitaldaemon.com>, Walter says...

What isn't guaranteed is the object being collected. If it *is*




collected,

the destructor will be run.


 New questions then.

 In what circumstances will the object be collected?


When the gc runs a collection and it cannot find a reference to that object.


 In what circumstances will the object not be collected?


When there's a reference to it somewhere in the 'roots' scanned by the gc.
The roots are things like the stack, registers and static data.
Jun 09 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

<snip>

 What isn't guaranteed is the object being collected. If it *is* collected,
 the destructor will be run.


On the D for Win32 page, WinMain includes:

     gc_term();		// run finalizers; terminate garbage collector

Does this mean:

(a) it's necessary to manually call this function on exit to make sure 
everything's destructed?
(b) there's a subtle difference between "finalizers" and "destructors"?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jun 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:ca7emf$30cm$1 digitaldaemon.com...

 Walter wrote:

 <snip>

 What isn't guaranteed is the object being collected. If it *is*




collected,

 the destructor will be run.


 On the D for Win32 page, WinMain includes:

      gc_term(); // run finalizers; terminate garbage collector

 Does this mean:

 (a) it's necessary to manually call this function on exit to make sure
 everything's destructed?


Yes. But recall that this is rarely necessary, the OS will routinely clean
up any dangling resources on the exit of a process.


 (b) there's a subtle difference between "finalizers" and "destructors"?


There is no difference in D.
Jun 09 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:


 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:ca7emf$30cm$1 digitaldaemon.com...


<snip>

 (a) it's necessary to manually call this function on exit to make sure 
 everything's destructed?


 
 Yes. But recall that this is rarely necessary, the OS will routinely clean 
 up any dangling resources on the exit of a process.


<snip>

Yes, Win98 seems to free system resources when the program exits, as I 
discovered while fixing Empire.  I'm quite sure Win3.x didn't, but 
that's history now.  And I'm not sure about Win95.

Also, if a file/database class has write-caching, it's important to make 
sure the changes are indeed finally written out.  While doing Fortran 
stuff it didn't take me long to notice that if an output file isn't 
closed when the program exits, there tends to be quite a lot of lost 
output that never made it to the file.  But then again, Fortran has its 
quirks, like FLUSH being nonportable....

Of course, if the app is supposed to be failsafe, it would manually 
flush the cache from time to time anyway....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jun 10 2004