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

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

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

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

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

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

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

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

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

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