C garbage collection -crazy idea

[onkar]

This idea might be vey crazy. But I hope to get answers to this .. from
comp.lang.c

If a compiler is designed such that it automatically adds a free()
matching every malloc()
then is it not a garbage collection (in the first place , garbage will
not be generated !! ) . Is it
possible to have a compiler with such feature. Or if Its not a good
idea (or may be this is an idiotic idea) please tell me why is it so ??

Thanks,

[Richard Heathfield]

in**@coverageme ter.com said:

<snip>

You can allocate on the stack and not on the heap.
in this case the memory will be freed automatically
when leaving the function.

See 'man alloca'

But bear in mind that alloca() may not be available on your system. It is
not a standard C library function.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[goose]

Roland Pibinger wrote:

On 15 Dec 2006 03:59:10 -0800, "goose" wrote:

How would the compiler react to this?

int x, i;
...
int **foo = malloc (sizeof *foo * x);
...
for (i=0; i<x; i++) {
foo[i] = malloc (sizeof *foo[i]);
}
...

How many calls to free should there be, and where should
they be placed?

How would you do it manually? The compiler would roughly do the same.

It cannot; it does not have enough information at compile-time
to determine how many free() calls are needed. What if I read the
value x from a file at runtime?

goose,

[Keith Thompson]

"goose" <ru**@webmail.c o.zawrites:

Roland Pibinger wrote:

>On 15 Dec 2006 03:59:10 -0800, "goose" wrote:

>How would the compiler react to this?

int x, i;
...
int **foo = malloc (sizeof *foo * x);
...
for (i=0; i<x; i++) {
foo[i] = malloc (sizeof *foo[i]);
}
...

How many calls to free should there be, and where should
they be placed?

How would you do it manually? The compiler would roughly do the same.

It cannot; it does not have enough information at compile-time
to determine how many free() calls are needed. What if I read the
value x from a file at runtime?

The compiler can generate a loop as easily as you can. But I'd be
very very surprised if something like this could be implemented
usefully.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Tobin]

In article <6v************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>If a compiler is designed such that it automatically adds a free()
matching every malloc()

>...then you wouldn't be able to use it for translating any existing C
programs that correctly call free().

It could do what existing garbage collectors for C do, and replace
free() with a no-op function. Of course, when he said the compiler
would add calls to free() he meant real_free().

>And how would it know when to call free()? I'll be the judge of that, thank
you.

If you could correctly judge it for all my programs, it would be very
helpful.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[William Hughes]

Keith Thompson wrote:

"goose" <ru**@webmail.c o.zawrites:

Roland Pibinger wrote:

On 15 Dec 2006 03:59:10 -0800, "goose" wrote:
How would the compiler react to this?

int x, i;
...
int **foo = malloc (sizeof *foo * x);
...
for (i=0; i<x; i++) {
foo[i] = malloc (sizeof *foo[i]);
}
...

How many calls to free should there be, and where should
they be placed?

How would you do it manually? The compiler would roughly do the same.

It cannot; it does not have enough information at compile-time
to determine how many free() calls are needed. What if I read the
value x from a file at runtime?

The compiler can generate a loop as easily as you can. But I'd be
very very surprised if something like this could be implemented
usefully.

Why? alloca can be implemented in such a way that it allocates from
the "heap" not the "stack". Basically, to implement a malloca, you
just call malloc and keep a list of things you need to free along with
the point at which you need to free them. If you design your functions
to use a single exit point then you can do this yourself, you don't
even need compiler support (with the minor proviso that if a variable
goes out of scope there is a "memory leak" till the end of the
function).

- William Hughes.

- William Hughes

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[SM Ryan]

"onkar" <on*******@gmai l.comwrote:
# This idea might be vey crazy. But I hope to get answers to this .. from
# comp.lang.c
#
# If a compiler is designed such that it automatically adds a free()
# matching every malloc()

If you want automatic garbage collection, use the auto or register
storage class.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Death is the worry of the living. The dead, like myself,
only worry about decay and necrophiliacs.

[Richard Heathfield]

Richard Tobin said:

In article <6v************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

<snip>

>>And how would it know when to call free()? I'll be the judge of that,
thank you.

If you could correctly judge it for all my programs, it would be very
helpful.

If the rate is right...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Greg Johnston]

onkar wrote:

This idea might be vey crazy. But I hope to get answers to this .. from
comp.lang.c

If a compiler is designed such that it automatically adds a free()
matching every malloc()
then is it not a garbage collection (in the first place , garbage will
not be generated !! ) . Is it
possible to have a compiler with such feature. Or if Its not a good
idea (or may be this is an idiotic idea) please tell me why is it so ??

Thanks,

First of all, you might want to check out the Boehm-Demers-Weiser GC
(http://en.wikipedia.org/wiki/Boehm_GC for basic information,
http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for the home page).

What you're describing isn't exactly garbage collection. GC is usually
dynamic, rather than static.

[Giorgos Keramidas]

On Fri, 15 Dec 2006 13:40:18 GMT, rp*****@yahoo.c om (Roland Pibinger) wrote:

On 15 Dec 2006 05:11:33 -0800, "Lew Pitcher" wrote:

>>Roland Pibinger wrote:

>>The compiler just needs to add the 'free' call(s) in the same scope
in which *alloc is called (in inverse order).

Nope. Not a good idea.
There are many examples where the results of malloc() are or can be
passed out of scope, to the next level higher. I certainly don't want
my compiler to throw away the deliberately malloc()ed memory that my
node allocation function in my binary tree builder grabbed. It is up
to the node deallocation function to do that.

Ok, then call those functions lmalloc ('local malloc') ... and
everything is clear. You can assign locally allocated memory to local
variables and pass it to other functions but you cannot return it or
assign it to non-local variables. In a sense alloca does something
similar (but only on the stack).

This doesn't really solve the problem Lew Pitcher described.

One of the features of the current malloc()/free() model is that you can
allocate an object deeply inside the call stack, i.e. when the program's
call stack looks like:

main()
copytree()
maketree()
makenode()
malloc()

Return the pointer to the malloc'd object all the way up to copytree(),
do some other unrelated work (i.e. sort the nodes of the tree), and then
free() the allocated memory in a different place, deeply inside another
call stack:

main()
savetree()
writenode()
deletenode()
free()

By forcing all free() operations to be always in the same scope of their
respective malloc() call, you cannot use this programming model.