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

 

[Malcolm]

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.

There's something to be said for garbage collection.

One problem is that failure to free() a pointer often doesn't just indicate
that the programmer forgot to make the call, but that there is something
else wrong with the algorithm. masking this might make such bugs harder to
find.

 

[Serve La]

There's something to be said for garbage collection.

One problem is that failure to free() a pointer often doesn't just indicate
that the programmer forgot to make the call, but that there is something
else wrong with the algorithm. masking this might make such bugs harder to
find.

I really don't understand what you mean here. Please give an example of a
wrong algorithm where memory isn't freed.

If you mean that the algorithm is wrong in the sense that some code paths
don't come across the free's, that's exactly what you win with GC.

 

[jacob navia]

I admit that I like lcc, even in its win32 incarnation. However, this is
the second thread in the last few days in which you have been pushing this
product. Since it is available free, calling what you are doing spamming
is not accurate. But it is certainly redolent of spam.

Hi Martin
Yes, it is promoting lcc-win32. I have been working the last 8 years into making it a nice compiler,
and I would like that people know about it, and all the features I have been adding to it.

As far as I know, it is the only C compiler where there isn't a C/C++ tag on it. It is a C compiler,
albeit a modern one. I believe in this language because of its simplicity and power of expression. I
wanted to stress that GC is available in C, not only in JAVA (tm) or C# (tm). By the way, when we
speak here about trade-mark products like JAVA or C# isn't it that "pushing" a product?

I have no publicity budget so I have to promote lcc-win32 the old way: by just saying it so.

Sorry if I disturbed you

jacob

 

[Serve La]

As far as I know, it is the only C compiler where there isn't a C/C++ tag

on it.

Uhoh, now you'll get a list of "pure" C compilers

It is a C compiler,
albeit a modern one. I believe in this language because of its simplicity

and power of expression.

This is what most people say about C and I agree.

No specialized template arguments with default value, generating source for
a member function template policy class that's using a protected friend
which it also inherits from but without a virtual destructor
It's way out of control with these C++'ers.

 

[Malcolm]

I really don't understand what you mean here. Please give an example > of

a wrong algorithm where memory isn't freed.You've got a linked list. You insert and delete sub-lists in amny places in
your code.
In one place, you make a mistake, so that a section of nodes is orphaned.
Really they were meant to be appended to the tail of the list but omitted
the line
last->next = sublist;

Now if you don't have garbage collection, on freeing the list the orphan
nodes won't be freed. Using a leak detector, you will see "memory leak" and
"oh no, something is wrong here. Eventually you will come to your error.
The real problem is not that you are wasting a few bytes of memory on the
orphan nodes, but that they should be appended to the main list. They might
be objects for collision detection, for instance, and it might not be
immediately obvious that some items are missing.

 

[Serve La]

You've got a linked list. You insert and delete sub-lists in amny places in
your code.
In one place, you make a mistake, so that a section of nodes is orphaned.
Really they were meant to be appended to the tail of the list but omitted
the line
last->next = sublist;

Now if you don't have garbage collection, on freeing the list the orphan
nodes won't be freed. Using a leak detector, you will see "memory leak" and
"oh no, something is wrong here.

two things:
1. you don't need a memory leak detector for errors like that. A test case
and a test run would show you that the data isn't added properly.
2. if you clutter your code with linked list logic all over the place, you
don't need a memory leak detector to tell you you have a problem.

 

[Malcolm]

two things:
1. you don't need a memory leak detector for errors like that. A test
case and a test run would show you that the data isn't added properly.

No, but you will find the bug quicker with the leak detection.

2. if you clutter your code with linked list logic all over the place, you
don't need a memory leak detector to tell you you have a problem.

Sometimes it isn't easy to write neat programs. Maybe the fact that we have
such a bug tells us that the time has come to do some surgery on the code.

Checking that free() is invoked correctly shouldn't be your only or even
your major bug-detecting strategy. However forcing programmers to explicitly
free() all memory they allocate is often useful in showing up design flaws.

 

[jacob navia]

[snip]
Checking that free() is invoked correctly shouldn't be your only or even
your major bug-detecting strategy. However forcing programmers to explicitly
free() all memory they allocate is often useful in showing up design flaws.

It *could* be. But garbage collection is a great tool when you want to avoid nasty freeing bugs like
making sure all aliases to the object you are going to free are dead and they will never be used
again.

There is "magic bullet" of course, I am not trying to sell you something since my compiler system is
free. It is a great tool for PC applications, where there are no real time and memory constraints.

 

[jacob navia]

On Sun, 10 Aug 2003 10:34:43 +0200, in comp.lang.c , "jacob navia"

(advertising)

I seem to recall that advertising, even for nominally free products,
is frowned upon in CLC, even possibly against the posting rules.

Garbage collection is not something that can be done only in JAVA or C#. There was a thread that
discussed those messages, a few posts ago. I think it is important to underline that garbage
collection was done in C well before those languages even existed.

Doesn't bother me, although it increases the likelihood of me never
using the product,

Yes, it is a good attitude. Do not use it if you like. this is a forum, and everyone is entitled to
their opinions.

but your post is additionally offtopic as far as I
can see,

Garbage collection is a necessary thing that has been always frowned upon in forums, by people that
seem to like those horrible sessions of malloc/free debugging.

One of the main advantages I always hear of "Java over C" or "C# over C" is the

"We have garbage collection guys. You don't".

It is simply not true. I think advertising what Mr Boehm has done, and I suppose you do not doubt
the quality of his work, is on topic here. This modifies a lot the language itself.

For instance, we always hear about the destructors in other languages that automatically reclaim
memory. Well, with a GC you do not need that you see?

There is no need either to use complicated setjmp/longjmps to "cleanup" when you do a longjump
somewhere else, freeing all those blocks of memory. They will be freed automatically.

And, above all, there is no longer that incredibly tedious accounting chores!

The simplification in programming is staggering. How much time we have lost tracking those memory
allocation bugs?

has a misleading Subject line,

No. The subject line is crystal clear: "Garbage collection in C". Isn't that very clear to you?

and is hyperbolic to boot.

Nothing "hyperbolic there" but just the facts. The facts that are always frowned upon in this forums
by a kind of "conservativism" where we put the C language as a frozen block of specs that we can
never improve.

Garbage collection improves the programming in C, and simplifies system construction. No longer is
it necessary to keep an error-prone accounting of each memory block you see?

This sounds like an hyperbole because it sounds immedately so good that it looks exaggerated. But it
is not. It is really better.

That I don't like.

Like, dislike.

Let's discuss the issues Mark. The issues here are clear.

What is your opinion?

You didn't tell us at the end.

jacob

 

[Gordon Burditt]

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?

Does it correctly NOT free structures when pointers to them are
stored in a file, and later read back and used (during the same
execution of the program)? I believe this is allowed under ANSI C
and should not yield undefined behavior.

Gordon L. Burditt

 

[CBFalconer]

.... snip ...

Garbage collection improves the programming in C, and simplifies
system construction. No longer is it necessary to keep an
error-prone accounting of each memory block you see?

This sounds like an hyperbole because it sounds immedately so
good that it looks exaggerated. But it is not. It is really
better.

You miss the point. The subject here is **portable** C
programming. Anything that is not portable to any compliant C90
or C99 (or even K&R) C compiler is OFF-TOPIC. Code written for
your extensions is highly non-portable, in fact it will not even
function on Windows with other compilers.

Now consider the following erroneous code, written assuming your
GC is in effect:

#define FREE(x) (x = NULL) /* your recommendation, I believe */

p = malloc(n * sizeof *p);
q = p;
/* use p and q */
FREE(p);
/* code using q */
FREE(q);

and failures in "code using q" are going to occur dependant on
when the GC system gets around to actually freeing p. With a
proper free of p ANY further use of q may trigger a run time error
on good quality systems - at any rate the action is probably
repeatable. A free of q should certainly trigger an error.

Now consider something like:

p = malloc(n * sizeof *p);
....
p++;
.... /* does the memory get destroyed in here? */
p--;
free(p);

which I believe to be completely valid C coding.

In addition your messages have excessive line length. No line
should exceed 80 characters, and 65 is much better.

 

[Derk Gwen]

# 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:

As Boehm's code explains, it doesn't work on some programs (which disguise their
pointers).

 

[jacob navia]

Does it correctly NOT free structures when pointers to them are
stored in a file, and later read back and used (during the same
execution of the program)? I believe this is allowed under ANSI C
and should not yield undefined behavior.

No.

If you have no pointers in RAM to an object it will be freed.

This is definitely NOT an application for a GC. The same if you
store pointers under the operating system control, like storing
pointers in the window extra bytes, under win32. Those objects
will not be visible to the GC and will be freed.

 

[jacob navia]

You miss the point. The subject here is **portable** C
programming.

I repeat:
The work of Mr Boehm has been ported to windows, linux, and sun, among many others.
It is perfectly portable code in the greate majority of cases.

Anything that is not portable to any compliant C90
or C99 (or even K&R) C compiler is OFF-TOPIC.

Ok. We then go to the seventies. Ahhh what a big time then...

Code written for
your extensions is highly non-portable, in fact it will not even
function on Windows with other compilers.

Yes. No other C compiler under windows features a GC as standard environment.
But you can use the GC dll with code compiled by ANY windows compiler. Just
load the library (gc.dll) and you are done.

Now consider the following erroneous code, written assuming your
GC is in effect:

#define FREE(x) (x = NULL) /* your recommendation, I believe */

p = malloc(n * sizeof *p);
q = p;
/* use p and q */
FREE(p);
/* code using q */
FREE(q);

and failures in "code using q" are going to occur dependant on
when the GC system gets around to actually freeing p.

Yes. The same behavior as free().

With a
proper free of p ANY further use of q may trigger a run time error
on good quality systems - at any rate the action is probably
repeatable.

If free() destroys the data contained in the memory block, filling it
with data designed to provoke traps you MAY get an error if the
data contained pointers. Maybe you get bad results, that is all. The
same behavior as the gc.

A free of q should certainly trigger an error.

On many systems freeing an object twice will provoke corruption of the
malloc system.

Now consider something like:

p = malloc(n * sizeof *p);
....
p++;
.... /* does the memory get destroyed in here? */

NO, since there is a pointer to the inner part of the object

p--;
free(p);

which I believe to be completely valid C coding.

It is

In addition your messages have excessive line length. No line
should exceed 80 characters, and 65 is much better.

Yes, I know. We are in the seventies and your terminal is an IBM3270.

 

[Andre]

and say, "Aha! Your problem must be with either 'mystruct' or
'mystruct->name'!" because the actual problem might be three
translation units away, in the line

pork = NULL;

and it simply happens that the GC has finally gotten around to
deleting 'pork', and has caused an error in the process (perhaps
the contents of '*pork' contain a pointer to 'mystruct', and
somewhere earlier the GC lost track of the reference count,
so that freeing 'pork' frees 'mystruct' unintentionally; maybe
something else happens).

In regard to this comment only, what you said cannot happen. If contents
of *pork contain a pointer to mystruct then the GC will not under any
circumstances decide to delete pork, at least not Bacon's Refernce
counting algorithm. Circular references are not a problem in many modern
ref-count GCs, namely Jikes RVM's JMTk (Jikes Memory management Toolkit).

-Andre

 

[Alan Balmer]

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.

Where did you get the idea that garbage collection was invented two
years ago by Lcc-win32? Garbage collection was invented many years
before Java, C# or Windows existed.

 

[Alan Balmer]

On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space. I suggest you start your own newsgroup.

 

[jacob navia]

On Mon, 11 Aug 2003 02:22:38 +0200, "jacob navia"

and wrote, and wrote, and ...

I ignored the advertising the first time, but I am now very close to
filtering your messages as a continuing waste of my time and disk
space.

Please do so.

Your message is so constructive and full real arguments, that I think
it is better to ignore it.

comp.lang.c according to you, is designed to answer questions like

HELP HELP!!!

I wrote
p[i++] = ++i;

and it doesn't work.

Serious discussions that go beyond the usual newbee questions should
go elsewhere. Obviously.

jacob

 

[Zeljko Vrba]

Yes, I know. We are in the seventies and your terminal is an IBM3270.

I don't know about his terminal, but I read news in an 80x25 xterm. And
have many xterms on several virtual desktops. An I get really annoyed
when I have to resize one of the just to read news. I read your postings
(scrolling left and right) just because of your name. If somebody else
posted an article with too long lines, I'd just ignore his post. And
so would many other people.