Garbage collection problems

[jacob navia]

As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

I am aware however, that nothing is "the silver bullet", not
even the GC.

A recent article in slashdot
http://developers.slashdot.org/artic.../11/17/0552247
proves that.

A C# application was leaking memory, and the application would
become slower and slower because the memory was getting full and the
system was swapping like mad until it just failed.

Why?

Because a list that should be destroyed wasn't being destroyed.
This is similar to another bug that Sun discovered in their
Java implementation. The list wasn't being destroyed because
SOMEWHERE there was a reference to that list, and the GC could
not destroy it.

It is interesting to note that this bug is as difficult to trace as
a missing free or similar bugs. It required a specialized tool
to find it (yes, there are specialized tools to solve GC memory
allocation problems as there are specialized tools to solve
non-gc memory allocation problems)

The lesson to be learned is that you have to be careful (when using the
GC) to
1) Set all pointers to unused memory to NULL.
2) Do NOT store pointers to GC memory in permanent structures if you
want that data to eventually be collected.

The above bug was that the list registered itself in a global
data structure and wasn't getting destroyed.

If the GC wouldn't have been there, the programmer would have freed
the memory, what would have closed the memory leak but left
a dangling pointer in the global data structure!

Not a better alternative.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

jacob navia <ja***@nospam.o rgwrites:

As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

<snip bugs caused by leaving data erroneously referenced>

The lesson to be learned is that you have to be careful (when using the
GC) to
1) Set all pointers to unused memory to NULL.

You claimed to want a technical discussion of your suggestions about
GC, but you did not respond to my point about this very issue. Do you
propose (and has your compiler implemented) a new set of "as if" rules
so that such settings can not optimised away?

--
Ben.

[jacob navia]

Ben Bacarisse wrote:

jacob navia <ja***@nospam.o rgwrites:

>As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

<snip bugs caused by leaving data erroneously referenced>

>The lesson to be learned is that you have to be careful (when using the
GC) to
1) Set all pointers to unused memory to NULL.

You claimed to want a technical discussion of your suggestions about
GC, but you did not respond to my point about this very issue. Do you
propose (and has your compiler implemented) a new set of "as if" rules
so that such settings can not optimised away?

An assignment can't be optimized away unless the compiler
proves that this memory can't be used within the current scope.

If your compiler does that, nothing happens because when you
exit that scope the GC will see that the memory is no longer
referenced.

Many complications can arise. My compiler only does such
optimizations when asked for. In a GC setting just avoid for
asking those optimizations (delete unused assignments).
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Tor Rustad]

jacob navia wrote:

As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

Right, but I'm more interested in knowing what Richard Heathfield would
have liked C99 to include, but C99 didn't. :)

I am aware however, that nothing is "the silver bullet", not
even the GC.

IMO, the main domain of C is system and embedded development. Even if
extending this domain by including communication, security development
and DB engine development, a GC seems neither important, or of much
interest.

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[jacob navia]

Tor Rustad wrote:

jacob navia wrote:

>As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

Right, but I'm more interested in knowing what Richard Heathfield would
have liked C99 to include, but C99 didn't. :)

Yes, that is obvious. You live and love for R.H.

But (maybe) you could spare me to know the details.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

jacob navia <ja***@nospam.c omwrites:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.o rgwrites:

>>As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

<snip bugs caused by leaving data erroneously referenced>

>>The lesson to be learned is that you have to be careful (when using the
GC) to
1) Set all pointers to unused memory to NULL.

You claimed to want a technical discussion of your suggestions about
GC, but you did not respond to my point about this very issue. Do you
propose (and has your compiler implemented) a new set of "as if" rules
so that such settings can not optimised away?

An assignment can't be optimized away unless the compiler
proves that this memory can't be used within the current scope.

If your compiler does that, nothing happens because when you
exit that scope the GC will see that the memory is no longer
referenced.

You miss my point. Conservative GC is always "safe" since anything that
even looks like a reference will prevent memory from being freed, but
someone asked what happens when you free a malloc'd block of pointer to
GC_malloc'd memory. E.g., given a tree whose nodes are "collectabl e":

void do_stuff(struct tree *root)
{
struct tree **locals = malloc(100 * sizeof *locals);

/* fill is with pointers to things that might be collectable */
/* use these pointers and then: */

memset(locals, 0, 100 * sizeof *locals);
free(locals);
}

The memset was your solution to the memory block about to disappear,
but a compiler is allowed (I think) to optimise it away since the
pointer is about to become invalid (by being free'd) and will then
vanish. Eventually, in practice, the memory is likely be used again
and then the pointers might get overwritten and the memory can finally
be collected (if no other pointers reference it) but nothing in the
way C is currently defined ensures that this will happen.

I think some changes to what a compiler may or may not do are implied
if your suggestion is to be truly predictable. For it to be a viable
proposal you'd need to say what implications it has for C in general,
not just what your compiler does. I suspect that you can get round
all the problems simply by saying that your new standard C will not
guarantee that GC_malloc's memory will ever be collected.

--
Ben.

[cr88192]

"jacob navia" <ja***@nospam.o rgwrote in message
news:47******** *************** @news.orange.fr ...

As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

I am aware however, that nothing is "the silver bullet", not
even the GC.

A recent article in slashdot
http://developers.slashdot.org/artic.../11/17/0552247
proves that.

A C# application was leaking memory, and the application would
become slower and slower because the memory was getting full and the
system was swapping like mad until it just failed.

Why?

Because a list that should be destroyed wasn't being destroyed.
This is similar to another bug that Sun discovered in their
Java implementation. The list wasn't being destroyed because
SOMEWHERE there was a reference to that list, and the GC could
not destroy it.

<snip>

>
If the GC wouldn't have been there, the programmer would have freed
the memory, what would have closed the memory leak but left
a dangling pointer in the global data structure!

Not a better alternative.

this is why I tend to use a hybrid approach.
I use a GC, but, much of the time, use manual memory management approaches.

major reason:
freeing memory faster means it can be reallocated faster.

so, yes, a lot of data does not need to be collected, and the GC is only
ever invoked rarely.

this is much better in general than spewing out masses of garbage and
expecting the GC to clean it up, as, even when it does, it is not
necessarily fast about it (though, my GCs are not often too terribly slow,
they can create delays and jumps, which are annoying, among other possible
issues).

thus, better performance...

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[llothar]

You miss my point. Conservative GC is always "safe" since anything that

even looks like a reference will prevent memory from being freed, but

Bullshit.

Judy Arrays or any other code that computes pointers but doesn't
store them are not safe for conservative GC's (well they aren't safe
in
other GC implementations , but mostly then they are impossible because
of
forbidden pointer arithmetic).

Maybe you should at least read the README.txt of Boehms GC before
talking
about Garbage Collection.

[cr88192]

"Tor Rustad" <to********@hot mail.comwrote in message
news:w6******** *************@t elenor.com...

jacob navia wrote:

>As many people know, I think that garbage collection is a good
solution for many memory allocation problems.

Right, but I'm more interested in knowing what Richard Heathfield would
have liked C99 to include, but C99 didn't. :)

>I am aware however, that nothing is "the silver bullet", not
even the GC.

IMO, the main domain of C is system and embedded development. Even if
extending this domain by including communication, security development and
DB engine development, a GC seems neither important, or of much interest.

errm, are you trying to claim that all of us good old desktop-pc developers
are all off using stuff like Java and C# or something?...

I say, no...
must of us are in a land where we still want things like GC, but don't feel
like selling our souls to some proprietary VM framework to get it.

C and C++ are still plenty strong on the desktop...

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[Richard Heathfield]

cr88192 said:

<snip>

must of us are in a land where we still want things like GC

By what authority do you speak for "must of us"?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999