Re: Garbage collection


"Douglas A. Gwyn" <DAGwyn@xxxxxxxx> wrote in message news:470FF3D7.753D1B0E@xxxxxxxxxxx
"Dr A. N. Walker" wrote:
In article <470F88E9.96A4F9B8@xxxxxxxx>,
Douglas A. Gwyn <DAGwyn@xxxxxxxx> wrote:
>GC is not needed if the program is invoking destructors properly, and
>could be dangerous if it isn't.
??? If GC is "dangerous", then it is because it contains a
bug, which is nothing to do with [de]allocation or destructors. If
GC "collects" some object, then it is because it believes, rightly
or wrongly, that the program has no defined way of ever accessing the
object again. If it is wrong, then the GC needs fixing [just as a
bug in the compiler or the OS needs fixing -- but once fixed, it
should then work!], and if it is right, then it is simply doing a
useful job of tidying up.
If a program is not invoking destructors properly, should
we not put the blame on the incorrect program, rather than on an
inoffensive garbage collector?

I assume the GC is not invoking destructors (how could it, without
tagged types?).

we don't need tagged types to handle destructors...
all we need is some means of associating the destructor with an object.

this could be done per-type (I have types, but not tagged references, rather types are part of the pointed to object and hidden away from any code using them), or it could be done per object (the primary downfall being mostly that this is more expensive, and also requires more effort if done poorly).


It's the failure to close out the lifetime of an
object without invoking its destructor that is dangerous, for
example not committing buffered changes to a database.

then the programmer is a retard.
no one ever said that C was a language for retarded newbs, rather it is a language for people who know (more or less) WTF they are doing...

and, on this token, a person who is retarded enough to screw up with GC, is more than enough to screw up with manual memory management.


As a matter
of programming psychology, if the programmer is dependent on GC to
"clean up objects when they are no longer needed", that programmer
is more likely to neglect to invoke needed destructors, and the GC
mechanism won't take care of that for him. On the other hand, if
a programmer is properly invoking destructors, there is no garbage
left to clean up!

this reasoning does not scale, IMO...

and, of course, see my comment above about tards and newbs.


in my reasoning, it is better, yes, to free up objects as soon as possible (after all, this saves memory footprint and generally makes performance better).


however, this is not always possible or reasonable, especially as an app becomes large or complicated (I will assert, probably much above, say, 100 kloc, one will 'feel the pain' as it were, if they have really experienced the various options).

absent GC, we end up with either overly rigid APIs having strict memory-handling or abstraction properties (for example, a common approach of not actually sharing any memory across API boundaries), or, also common (usually in less robust code), is deciding that it is too much effort and simply forgetting about dead memory in many cases (go locate and free all these strings allocated via strdup? no, nevermind, we simply forget about them...).

so, it provides a fallback in case of being faced with this latter option.
at least if some magic happens and our memory is released, rather than the app eventually using up all the ram or address space and crashing, it is a little better.


but, of one thinks GC means it is a good idea to be like:
byte *p=gcalloc(1<<20); //some largish buffer
.... do crap with buffer
//done with buffer so I no longer give a crap
//not even doing something as simple as 'gcfree(p);'
return;

they can be rightly kicked in an unpleasant place...


.

Relevant Pages

  • Re: Garbage collection
    ... I assume the GC is not invoking destructors (how could it, ... "clean up objects when they are no longer needed", ...
    (comp.std.c)
  • Re: Garbage collection
    ... bug, which is nothing to do with allocation or destructors. ... I assume the GC is not invoking destructors (how could it, ... is more likely to neglect to invoke needed destructors, ...
    (comp.std.c)
  • Re: Destructor: not gauranteed to be called?
    ... > implementation detail for destructors in C++. ... Destruction is a language ... Resource automatic freeing (mainly memory), ... The problem is that most developper know about finalizers (which ...
    (microsoft.public.dotnet.languages.vc)
  • Re: To C++ or not to C++
    ... >> Constructors and destructors can offer so much in the way of memory ... >> leak avoidance. ... each language can leak memory like a sieve ...
    (freebsd-hackers)
  • Re: Overloading new[]
    ... It would be prudent to run destructors before freeing the memory. ...
    (microsoft.public.vc.language)