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

 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

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

 Sorry for not being clear.

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

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

 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

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

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

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


the destructor.

How curious. In your post 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


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,

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

 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

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

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


the destructor.

How curious. In your post 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


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,

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

 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?
  

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

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

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?
 

      

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

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

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


the destructor.

How curious. In your post 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


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,

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

 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:

 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:


 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*


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*


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

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

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