Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Garbage collection problems

Reply
Thread Tools

Garbage collection problems

 
 
jacob navia
Guest
Posts: n/a
 
      11-18-2007
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
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-18-2007
jacob navia <(E-Mail Removed)> writes:

> 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.
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      11-18-2007
Ben Bacarisse wrote:
> jacob navia <(E-Mail Removed)> writes:
>
>> 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
 
Reply With Quote
 
Tor Rustad
Guest
Posts: n/a
 
      11-18-2007
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 <(E-Mail Removed) | tr i-za-h a-z>
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-18-2007
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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-19-2007
jacob navia <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:
>> jacob navia <(E-Mail Removed)> writes:
>>
>>> 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 "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.

--
Ben.
 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      11-19-2007

"jacob navia" <(E-Mail Removed)> wrote in message
news:47407247$0$27377$(E-Mail Removed)...
> 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



 
Reply With Quote
 
llothar
Guest
Posts: n/a
 
      11-19-2007
> 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.

 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      11-19-2007

"Tor Rustad" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 <(E-Mail Removed) | tr i-za-h a-z>



 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-19-2007
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory problems (garbage collection) Carbon Man Python 6 04-29-2009 11:16 AM
IE6 Garbage Collection and general IE6 slowness problems timothytoe Javascript 4 06-03-2008 05:17 PM
Collection problems (create Collection object, add data to collection, bind collection to datagrid) yvind Isaksen ASP .Net 1 05-18-2007 09:24 AM
Garbage collection problems with a c++ wrapper for a module James S Python 2 07-20-2004 01:22 AM
Debbugging help! (.NET 1.1 Framework Garbage Collection Problems) Cheung, Jeffrey Jing-Yen ASP .Net 3 07-10-2003 07:29 PM



Advertisments