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/article.pl?sid=07/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.

 

[Ben Bacarisse]

As many people know, I think that garbage collection is a good
solution for many 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.

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?

 

[jacob navia]

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

 

[Tor Rustad]

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.

 

[jacob navia]

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.

 

[Ben Bacarisse]

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 "collectable":

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.

 

[cr88192]

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/article.pl?sid=07/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.

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

 

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

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


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

 

[Richard Heathfield]

cr88192 said:

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

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

 

[Ben Pfaff]

cr88192 said:

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

I think that most of us want the memory allocator to magically do
the right thing in every instance without any effort on our part.
Some people call this magic wonderment "garbage collection".

 

[Richard Heathfield]

Ben Pfaff said:

I think that most of us want the memory allocator to magically do
the right thing in every instance without any effort on our part.

Again, who is "most of us"?

I don't want the MM subsystem to get creative. I want it to do exactly what
I tell it to do, exactly when I tell it to do it.

 

[Richard Tobin]

You miss my point. Conservative GC is always "safe" since anything that
even looks like a reference will prevent memory from being freed

In C, you do have to keep pointers as things that look like a
reference. You can memcpy() the bits of a pointer and shuffle them
up, wait a while, then unshuffle them and store them back in a
pointer. You can even print them out to a file. No GC is going to
handle that unaided.

-- Richard

 

[cr88192]

cr88192 said:



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

myself, many other people I talk to, ...

after all, if no one really wanted GC, then Java and C# would leave them
out, and things like Boehm, and the endless other custom GC frameworks,
would simply not be used.

but, of course, I don't speak for embedded developers really, mostly good
old desktop programmers...


GC by itself is not very expensive, but going over to something like Java or
C# is...
GC is worth the costs, but Java may not be.

and so on...

 

[Chris Dollin]

cr88192 said:



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

I can't answer that. I /can/ say that /I/ want GC.

And I've got it [1]. I just don't see that it's the right tool /for C/,
certainly not to the point where it would be a mandatory part of
the Standard. I see no harm in an implementation providing GC /as
an option/, so long as it's an honest global GC, and the implementation
makes it clear that its a non-Standard /option/.

I am a hedgehog of very little brain, and as well as long words bothering
me, I only have so much brain-power to give to my code; if I can give up
a significant part of store-management worries to the language /at an
acceptable price/, whizzo! I'm all for it, it leaves me free to attend
to other, less automatable, parts of program design.

[1] Because most of my work code nowadays is Java, and I've historically
used Lisp and Pop11 as well as implementing and then using languages
with GC.

 

[Richard Heathfield]

cr88192 said:

myself, many other people I talk to, ...

So "some people" rather than "most people", yes?

after all, if no one really wanted GC, then Java and C# would leave them
out,

Since the only relevant language here in comp.lang.c is C, and since C
doesn't have GC, we can deduce from your argument that no C programmer
really wants GC. (That's the trouble with logic - it can bite you back.)

and things like Boehm, and the endless other custom GC frameworks,
would simply not be used.

but, of course, I don't speak for embedded developers really, mostly good
old desktop programmers...

You don't speak for me, that's for sure.

 

[Richard Heathfield]

Chris Dollin said:

I am a hedgehog of very little brain, and as well as long words bothering
me, I only have so much brain-power to give to my code; if I can give up
a significant part of store-management worries to the language /at an
acceptable price/, whizzo! I'm all for it, it leaves me free to attend
to other, less automatable, parts of program design.

Sure, and I agree - but I remain unconvinced that it is available /at an
acceptable price/.

 

[cr88192]

cr88192 said:


So "some people" rather than "most people", yes?

some, or most, a difficult and not very solid argument...
one would then have to count to know one way or another.

Since the only relevant language here in comp.lang.c is C, and since C
doesn't have GC, we can deduce from your argument that no C programmer
really wants GC. (That's the trouble with logic - it can bite you back.)

or, a much simpler argument:
I am a C programmer, and I use GC in C, thus, there exist C programmers who
use GC.

a similar point can be made about the OP, or for that matter, the existence
of this, and many similar threads.
if no C programmers wanted GC, then they would have no reason to post in
comp.lang.c or comp.std.c (unless of course, they were covert C# or Java
coders, which using myself as an example, I am not).

You don't speak for me, that's for sure.

possible.

so, to the first question, are people like me or you the majority?...


well, no one says that all C programmers have to use GC, or that
standardization is particularly needed, the fact that Boehm is de-facto is
probably good enough.

it is much like OpenGL. many people use it, but it is fine as a 3rd party
library...

 

[cr88192]

Chris Dollin said:



Sure, and I agree - but I remain unconvinced that it is available /at an
acceptable price/.

so, which is more expensive?
GC, or OpenGL?...

a GC, or at least of the conservative variety, only has a minor (and often
largely ignorable) impact on general coding practice.

with GL, often, a good portion of the app's operation ends up being focused
on the GL way of doing things, and the needed support machinery to use it
effectively is not exactly minor (GL has good and bad points).

yet, many still use GL, and so, for someone like me, it does not ask "that"
much to use GC as well...

now, what about DirectX?...

....


feature that may effect certain edge cases, of feature that almost totally
changes how you would structure an app?...

 

[Chris Dollin]

Chris Dollin said:

Sure, and I agree - but I remain unconvinced that it is available /at an
acceptable price/.

In my experience, for the kind of programming that I do, it's been available
since the 80s.

Tradeoffs differ among domains.

[I'm happy taking a performance hit from dynamic typing, too.]