Garbage collection in C

[jacob navia]

Tired of chasing free(tm) bugs?

Get serious about C and use lcc-win32. The garbage collector designed by Boehm is the best of its
class. Very simple:

#define malloc GC_malloc
#define free(a) (a=NULL)

NICE isn't it?

No more chasing free() bugs, no more this incredible tedious accounting where it is SO easy to miss
some pointer. Leave to the machine what the machine does best: the boring accounting work and
concentrate in your algorithm, the thing humans do best and where machines fail.

Garbage collection is not restricted to Java or C#. Lcc-win32 introduced it more than 2 years ago in
the context of a Windows C implementation. A DLL you link with your program, a header file more, and
MANY hours of debugging less.

And this code is portable, since Boehm's work runs in many Unices, workstations and many types of
machines.

Garbage collection means less headaches for you, and simpler programs to maintain and debug. The
amount of buggy code that is dedicated to manage the allocation system can be significant and it is
by experience one of the most difficults part to debug.

Scrap it!

http://www.cs.virginia.edu/~lcc-win32

jacob

[Serve La]

"Dave Vandervies" <dj******@csclu b.uwaterloo.ca> wrote in message
news:bh******** **@tabloid.uwat erloo.ca...

In article <bh**********@n ews4.tilbu1.nb. home.nl>, Serve La <[e-mail]> wrote:

It's almost (almost) getting funny, the resistance you people are showing
against GC. Files are used totally differently. I have never seen anybody
including myself chasing an "fclose" bug, or closing an invalid file
pointer.

I have.

And I'm not about to suggest that GC-style resource management would
have made the code work, or even made the bug less of a problem.
It definitely wouldn't've made it easier to find.

There are more things in heaven and earth,
Than are dreamt of in your philosophy.

Yes , I know that of course. But I was commenting on the fact that when
somebody proposes a useful feature and all answers he get are "but my files
are not cleaned up automatically" , "it can hide bugs in my algorithms" ,
"it does not work on platform xyz" , "now I can't do free(malloc(10) );". Not
one positive answer. So the consensus among C people is that "GC is bad"?

[Andre]

No.. *that* particular GC implementation is bad.. not GC itself.

-Andre

Serve La wrote:

"Dave Vandervies" <dj******@csclu b.uwaterloo.ca> wrote in message
news:bh******** **@tabloid.uwat erloo.ca...

In article <bh**********@n ews4.tilbu1.nb. home.nl>, Serve La <[e-mail]>

wrote:

It's almost (almost) getting funny, the resistance you people are showing
against GC. Files are used totally differently. I have never seen anybody
including myself chasing an "fclose" bug, or closing an invalid file
pointer.

I have.

And I'm not about to suggest that GC-style resource management would
have made the code work, or even made the bug less of a problem.
It definitely wouldn't've made it easier to find.

There are more things in heaven and earth,
Than are dreamt of in your philosophy.

Yes , I know that of course. But I was commenting on the fact that when
somebody proposes a useful feature and all answers he get are "but my files
are not cleaned up automatically" , "it can hide bugs in my algorithms" ,
"it does not work on platform xyz" , "now I can't do free(malloc(10) );". Not
one positive answer. So the consensus among C people is that "GC is bad"?

[Serve La]

"Andre" <fo********@hot mail.com> wrote in message
news:3f******** @clarion.carno. net.au...

No.. *that* particular GC implementation is bad.. not GC itself.

The boehm collector? why?

[Arthur J. O'Dwyer]

On Wed, 13 Aug 2003, Serve La wrote:

"Andre" <fo********@hot mail.com> wrote in message
news:3f******** @clarion.carno. net.au...

No.. *that* particular GC implementation is bad.. not GC itself.

The boehm collector? why?

Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
maybe Boehm's GC is bad too; I'm not a GC expert.)

I already said this in a personal email exchange with Jacob, but
here's what I find annoying/incorrect about his GC:

1) GC in general does not fit into the C language.

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C. And if a program *does* run correctly without GC, why
on earth would you *add* GC to it? It's just library bloat at
that point.

2) This particular GC has a non-standard interface.

Jacob's first suggestion was to #define malloc GC_malloc. That
is AFAIK an invocation of undefined behavior, and isn't guaranteed
to work unless it is surrounded by

#ifdef __THIS_COMPILER _HAS_GC__

- except that of course the macro __THIS_COMPILER _HAS_GC__ does not
exist, so we're stuck with testing something defined by lcc-win32
(and, we hope, *only* by lcc-win32).

A much better interface would have been a #pragma directive; for
example,

#pragma LCCWIN32_GC

which requires much less thought by the programmer *and* has a better
chance IMHO of passing muster with the standards police. :)

3) The original proposal had a bug in it.

This is the #define free(a) (a=NULL) thing that several people pointed
out. Sure, it's trivial to fix, but the fact that it was included in
the proposal at all indicated that maybe Jacob hadn't put as much thought
into his design as he could have.

4) Real Programmers(tm) don't do garbage collection.

This one is a stereotype, of course, but you should realize that a lot
of the regulars in c.l.c are (or seem to be) Real Programmers(tm) .
They program in C because they like the fine control, the clean
interface, and the raw power that the language provides. Garbage
collection is an attribute of higher-level Quiche Eater languages like
Lisp and Java, and you just shouldn't expect a ticker-tape parade from
the C programmers when you try to introduce it into C. It's the
psychology of the thing. C's been around for more than 20 years now
without GC; if you want GC that bad, use a language that has it built
in. That's how it is.
That pretty much sums up the points I've seen against this GC.

HTH,
-Arthur

[jacob navia]

"Arthur J. O'Dwyer" <aj*@andrew.cmu .edu> wrote in message
news:Pi******** *************** *************@u nix47.andrew.cm u.edu...

On Wed, 13 Aug 2003, Serve La wrote:

"Andre" <fo********@hot mail.com> wrote in message
news:3f******** @clarion.carno. net.au...

No.. *that* particular GC implementation is bad.. not GC itself.
The boehm collector? why?

Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
maybe Boehm's GC is bad too; I'm not a GC expert.)

I already said this in a personal email exchange with Jacob, but
here's what I find annoying/incorrect about his GC:

1) GC in general does not fit into the C language.

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C. And if a program *does* run correctly without GC, why
on earth would you *add* GC to it? It's just library bloat at
that point.

With this logic you could say too:
1) library XYZ is not mentioned in the C standard
2) It is expected then, that any C program runs without the library XYZ
3) Therefore (!!!) library XYZ is BAD.
2) This particular GC has a non-standard interface.

Jacob's first suggestion was to #define malloc GC_malloc. That
is AFAIK an invocation of undefined behavior, and isn't guaranteed
to work unless it is surrounded by

#ifdef __THIS_COMPILER _HAS_GC__

- except that of course the macro __THIS_COMPILER _HAS_GC__ does not
exist, so we're stuck with testing something defined by lcc-win32
(and, we hope, *only* by lcc-win32).
The standard interface for the GC in lcc-win32 is:

#include <gc.h>

The ONLY thing to do then is:

#ifdef __LCC__
#include <gc.h>
#endif
3) The original proposal had a bug in it.

This is the #define free(a) (a=NULL) thing that several people pointed
out. Sure, it's trivial to fix, but the fact that it was included in
the proposal at all indicated that maybe Jacob hadn't put as much thought
into his design as he could have.

As I told you the *standard* interface is to call GC_free(), i.e.
#define free GC_free

This is 100% compatible with the free() interface. BUT I think it is
better to use
#define free(a) (a=NULL)
since
1) This destroys the pointer to the freed memory
2) Doesn't call GC_free() eliminating any free() errors. Normally
you do not use free()
4) Real Programmers(tm) don't do garbage collection.

This one is a stereotype, of course, but you should realize that a lot
of the regulars in c.l.c are (or seem to be) Real Programmers(tm) .
I see.
They program in C because they like the fine control, the clean
interface, and the raw power that the language provides. Garbage
collection is an attribute of higher-level Quiche Eater languages like
Lisp and Java, and you just shouldn't expect a ticker-tape parade from
the C programmers when you try to introduce it into C. It's the
psychology of the thing. C's been around for more than 20 years now
without GC; if you want GC that bad, use a language that has it built
in. That's how it is.

Look Arthur. As I told you I have an automatic drive. Many people are
real_drivers(tm )
and look at me with utmost comptent for saving me the effort of changing gears
several thousand times a day. I have seen with my own eyes a TAXI driver that
told me that.

"It doesn't hurt your hand at the end of the day?" I asked him.
Yes, he told me, but you know, this is driving, really, people that use
an automatic car are pimps.

I payed and left. The world is big and there must be people of all kinds
to fill it up.
Personally, I still use my automatic and if anybody calls me a pimp because
of that, I wouldn't care less.

Feel free to spend all that time debugging your manually done malloc/free
calls Arthur. It is your life, your programs.

But please do not try to forbid automatic garbage collection from the C language.
It is ridiculous, like if somebody would forbid automatic cars!!!

jacob

[Derk Gwen]

# one positive answer. So the consensus among C people is that "GC is bad"?

Never mistake the comp.lang.c clique for C people.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I'm not even supposed to be here today.

[Serve La]

"Derk Gwen" <de******@HotPO P.com> wrote in message
news:vj******** ****@corp.super news.com...

# one positive answer. So the consensus among C people is that "GC is bad"?
Never mistake the comp.lang.c clique for C people.

Well, I'd say there are a lot of pretty good and experienced C programmers
in here.

[Larry Doolittle]

Arthur J. O'Dwyer wrote:

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C.

There is a time and a place for C programs that clean up their
own mallocs. Long-running server processes, or user programs
that respond to an indefinitely long string of commands (text,
mouse-clicks, or brain waves, for all I care).

There is _also_ a time and a place for C programs that totally
ignore "memory leaks", and trust that the system will reclaim
any allocated memory when exit() is called. Obvious examples
are single-use programs on a "sufficient ly large" machine,
or programs that do one thing and exit (e.g., *nix basename(1)).

Finally, many C programs are used in a context where any use
of malloc() itself is considered a bug, because there is no
guarantee of success, and success is mandatory. So of course
in this case there are no free()'s either.

Of course, none of this changes Arthur's conclusion, that
GC in C is a bad idea. People might be tempted to use it
in order to quickly (and without deep understanding) convert
programs conceived as "single-use on a sufficiently large
machine" into production code, but that is a horrible idea
for many more reasons than memory allocation. I'm all in
favor of quick prototyping, but the conversion from prototype
to production code is nothing to be taken lightly.

- Larry

[Derk Gwen]

# With this logic you could say too:
# 1) library XYZ is not mentioned in the C standard
# 2) It is expected then, that any C program runs without the library XYZ
# 3) Therefore (!!!) library XYZ is BAD.

The clique has in fact opined in the past that only legitimate functions are those
defined in the standard or defined in full. Reference to any other functions is deemed
off topic to reduce the cognitive load on the clique. The resulting flame wars do not
reduce the traffic, but rather increase it; topics that can be dealt with a simple
answer instead erupt into hundreds of posts over many weeks whining about off topicness.
(The clique is of course permitted to veer off topic.)

# > This is the #define free(a) (a=NULL) thing that several people pointed
# > out. Sure, it's trivial to fix, but the fact that it was included in
# > the proposal at all indicated that maybe Jacob hadn't put as much thought
# > into his design as he could have.
# >
#
# As I told you the *standard* interface is to call GC_free(), i.e.
# #define free GC_free

A typical clique response is to whine excessively about trivial issues. The idea being
to frustrate people outside the clique into silence.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I have no respect for people with no shopping agenda.

[Jirka Klaue]

Derk Gwen wrote:
....

A typical clique response is to whine excessively about trivial issues. The idea being
to frustrate people outside the clique into silence.

I have the impression that momentary it is you, who is whining.

Jirka