www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC should call dtors

reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


http://digitalmars.com/d/class.html#destructors
# The garbage collector is not guaranteed to run the destructor for all
# unreferenced objects.

Why shouldn't the GC guarantee to run the destructors 
1) before freeing the space allocated by that object
2) at normal programm termination?

Thomas



-----BEGIN PGP SIGNATURE-----

iD8DBQFCUYKW3w+/yD4P9tIRAgJhAKCp5/FC0LQPlYWtoT5AtZd+0aA8gQCfTQxK
Ot3va5tKsbTHNowSYQ+QFU8=
=S6Je
-----END PGP SIGNATURE-----
Apr 04 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <mdc8i2-n15.ln1 lnews.kuehne.cn>, Thomas Kuehne says...
http://digitalmars.com/d/class.html#destructors
# The garbage collector is not guaranteed to run the destructor for all
# unreferenced objects.

Why shouldn't the GC guarantee to run the destructors 
1) before freeing the space allocated by that object
2) at normal programm termination?

I think this is because the GC is not guaranteed to release memory occupied by unreferenced objects. Kind of a bad example, but say I have something that might be a pointer containing a value that just happens to correspond to a valid memory address of an otherwise unreferenced object N. The GC does a sweep and doesn't recognize that N is unreferenced and therefore never frees it. Reference counting would eliminate this problem, though it would have performance implications. But my knowledge of GC implementation is quite limited. I don't suppose there's something that could be done with the language and/or GC that would eliminate this problem? Perhaps the GC could access type info in a way that it could identify and scan only references? Sean
Apr 04 2005
parent reply Nick <Nick_member pathlink.com> writes:
In article <d2s14r$2rfj$1 digitaldaemon.com>, Sean Kelly says...
I think this is because the GC is not guaranteed to release memory occupied by
unreferenced objects.  Kind of a bad example, but say I have something that
might be a pointer containing a value that just happens to correspond to a valid
memory address of an otherwise unreferenced object N.  The GC does a sweep and
doesn't recognize that N is unreferenced and therefore never frees it.

But why doesn't the GC free ALL memory at program termination? Is there any reason to sweep at all? Nick
Apr 04 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:d2s71u$1a9$1 digitaldaemon.com...
 But why doesn't the GC free ALL memory at program termination?

It doesn't need to, since the operating system will do that automatically.
Apr 04 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d2s71u$1a9$1 digitaldaemon.com>, Nick says...
In article <d2s14r$2rfj$1 digitaldaemon.com>, Sean Kelly says...
I think this is because the GC is not guaranteed to release memory occupied by
unreferenced objects.  Kind of a bad example, but say I have something that
might be a pointer containing a value that just happens to correspond to a valid
memory address of an otherwise unreferenced object N.  The GC does a sweep and
doesn't recognize that N is unreferenced and therefore never frees it.

But why doesn't the GC free ALL memory at program termination? Is there any reason to sweep at all?

I was referring to a sweep mid-run, which can happen if the GC runs out of room for new stuff. All memory will be freed automatically at program termination anyway, so the only reason to do a sweep then would be to trigger the dtors of any singletons still alive, and then only because these singletons may have open resource handles that may not be cleaned up properly by simply freeing the memory. This would be nice, but there are workarounds for this issue (registering such objects in an auto class in main, for example).
Apr 04 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d2sdln$95r$1 digitaldaemon.com...
 these singletons may have open
 resource handles that may not be cleaned up properly by simply freeing the
 memory.

This is something I was wondering as well - what about stuff in, say, video memory? Is that handled by the OS in the same way that system memory is? Or how about references to COM objects? They can't just be cleaned up by the OS - they usually need to have their .Release() called.
Apr 04 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:mdc8i2-n15.ln1 lnews.kuehne.cn...
 http://digitalmars.com/d/class.html#destructors
 # The garbage collector is not guaranteed to run the destructor for all
 # unreferenced objects.

 Why shouldn't the GC guarantee to run the destructors
 1) before freeing the space allocated by that object

It does.
 2) at normal programm termination?

Because it's slow to run the gc at termination, and pointless since the operating system will recover any left over resources.
Apr 04 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 2) at normal programm termination?

Because it's slow to run the gc at termination, and pointless since the operating system will recover any left over resources.

Interesting you say that because dmain2() calls gc_term which calls fullCollectNoStack which does a fullCollect with only the static data as roots. It was suggested ages ago to skip this final fullCollect but nothing changed. It seems like you agree but haven't updated phobos. Is this correct?
Apr 04 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d2si2c$egb$1 digitaldaemon.com...
 2) at normal programm termination?

Because it's slow to run the gc at termination, and pointless since the operating system will recover any left over resources.

Interesting you say that because dmain2() calls gc_term which calls fullCollectNoStack which does a fullCollect with only the static data as roots. It was suggested ages ago to skip this final fullCollect but

 changed. It seems like you agree but haven't updated phobos. Is this
 correct?

Yes. Though I'll just comment it out; sometimes people (for debugging reasons) want it on.
Apr 04 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter wrote:
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d2si2c$egb$1 digitaldaemon.com...
 
2) at normal programm termination?

Because it's slow to run the gc at termination, and pointless since the operating system will recover any left over resources.

Interesting you say that because dmain2() calls gc_term which calls fullCollectNoStack which does a fullCollect with only the static data as roots. It was suggested ages ago to skip this final fullCollect but

nothing
changed. It seems like you agree but haven't updated phobos. Is this
correct?

Yes. Though I'll just comment it out; sometimes people (for debugging reasons) want it on.

Hmm. Then folks would have to rebuild Phobos. And have somehow become aware that such a possibility exists in the first place.
Apr 05 2005
prev sibling parent xs0 <xs0 xs0.com> writes:
What if it was made a flag with default off? Most apps don't need it, so 
the default is ok, but when you really do need dtors called on app exit, 
you can still enable them with just a function call?

Although, simply executing dtors on program exit is a bad thing, because 
threads may still live that are manipulating those objects, so somewhat 
random things may happen (and just killing off those threads is not much 
better).

Perhaps a solution is to require that all user threads stop executing 
before dtors get called (of course, only when the flag is on), so in 
cases where a user does indeed use this functionality, he will be forced 
to do proper clean-up of threads, ensuring that the program state is 
self-consistent. Unless he wants to wait forever to exit the program, of 
course :) (furthermore, in single-threaded apps, this will not be an 
issue at all, as the only thread will obviously stop on calling exit)


xs0


Walter wrote:
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d2si2c$egb$1 digitaldaemon.com...
 
2) at normal programm termination?

Because it's slow to run the gc at termination, and pointless since the operating system will recover any left over resources.

Interesting you say that because dmain2() calls gc_term which calls fullCollectNoStack which does a fullCollect with only the static data as roots. It was suggested ages ago to skip this final fullCollect but

nothing
changed. It seems like you agree but haven't updated phobos. Is this
correct?

Yes. Though I'll just comment it out; sometimes people (for debugging reasons) want it on.

Apr 05 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 http://digitalmars.com/d/class.html#destructors
 # The garbage collector is not guaranteed to run the destructor for all
 # unreferenced objects.

digitalmars.D/3448 Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 05 2005