digitalmars.D - GC should call dtors
- Thomas Kuehne (14/14) Apr 04 2005 -----BEGIN PGP SIGNED MESSAGE-----
- Sean Kelly (12/18) Apr 04 2005 I think this is because the GC is not guaranteed to release memory occup...
- Nick (4/9) Apr 04 2005 But why doesn't the GC free ALL memory at program termination? Is there ...
- Walter (3/4) Apr 04 2005 It doesn't need to, since the operating system will do that automaticall...
- Sean Kelly (8/16) Apr 04 2005 I was referring to a sweep mid-run, which can happen if the GC runs out ...
- Jarrett Billingsley (6/9) Apr 04 2005 This is something I was wondering as well - what about stuff in, say, vi...
- Walter (5/11) Apr 04 2005 It does.
- Ben Hinkle (5/8) Apr 04 2005 Interesting you say that because dmain2() calls gc_term which calls
- Walter (5/14) Apr 04 2005 nothing
- Georg Wrede (4/24) Apr 05 2005 Hmm. Then folks would have to rebuild Phobos.
- xs0 (16/38) Apr 05 2005 What if it was made a flag with default off? Most apps don't need it, so...
-
Stewart Gordon
(7/13)
Apr 05 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://digitalmars.com/d/class.html#destructors 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
In article <mdc8i2-n15.ln1 lnews.kuehne.cn>, Thomas Kuehne says...http://digitalmars.com/d/class.html#destructors 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
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
"Walter" <newshound digitalmars.com> "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
In article <d2s71u$1a9$1 digitaldaemon.com>, Nick says...In article <d2s14r$2rfj$1 digitaldaemon.com>, Sean Kelly says...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).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?
Apr 04 2005
"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
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message news:mdc8i2-n15.ln1 lnews.kuehne.cn...http://digitalmars.com/d/class.html#destructors Why shouldn't the GC guarantee to run the destructors 1) before freeing the space allocated by that objectIt 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
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?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
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:d2si2c$egb$1 digitaldaemon.com...nothingInteresting 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 but2) 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.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
Walter wrote:"Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:d2si2c$egb$1 digitaldaemon.com...Hmm. Then folks would have to rebuild Phobos. And have somehow become aware that such a possibility exists in the first place.nothingInteresting 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 but2) 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.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
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...nothingInteresting 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 but2) 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.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
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://digitalmars.com/d/class.html#destructors<snip> http://www.digitalmars.com/drn-bin/wwwnews?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