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

[Ben Bacarisse]

jacob navia <ja***@nospam.orgwrites:

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.

[jacob navia]

Ben Bacarisse wrote:

jacob navia <ja***@nospam.orgwrites:

>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

[Tor Rustad]

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 <bw****@wvtqvm.vw | tr i-za-h a-z>

[jacob navia]

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

[Ben Bacarisse]

jacob navia <ja***@nospam.comwrites:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.orgwrites:

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

[cr88192]

"jacob navia" <ja***@nospam.orgwrote in message
news:47***********************@news.orange.fr...

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

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

"Tor Rustad" <to********@hotmail.comwrote in message
news:w6*********************@telenor.com...

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 <bw****@wvtqvm.vw | tr i-za-h a-z>

[Richard Heathfield]

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

[Ben Pfaff]

Richard Heathfield <rj*@see.sig.invalidwrites:

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"?

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".
--
"It wouldn't be a new C standard if it didn't give a
new meaning to the word `static'."
--Peter Seebach on C99

[Richard Heathfield]

Ben Pfaff said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>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"?

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

[Richard Tobin]

In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[cr88192]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:db*********************@bt.com...

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"?

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

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

[Chris Dollin]

Richard Heathfield wrote:

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"?

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.

--
Chris "one was pure functional" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard Heathfield]

cr88192 said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:db*********************@bt.com...

>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"?

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

[Richard Heathfield]

Chris Dollin said:

<snip>

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

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

[cr88192]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Hq******************************@bt.com...

cr88192 said:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:db*********************@bt.com...

>>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"?

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

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.

>

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

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

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

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

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

[cr88192]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Hq******************************@bt.com...

Chris Dollin said:

<snip>

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

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

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

[Chris Dollin]

Richard Heathfield wrote:

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

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

--
Chris "polymorphic" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard Heathfield]

cr88192 said:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

<snip>

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

You seem to have missed my point, which is only that "some" is a safe
claim, whereas "most" is not.

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

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

Indeed. Again, you seem to have missed my point, which is that your
argument was faulty. Had it not been, I would not have been able to turn
it back on itself.

if no C programmers wanted GC,

Undoubtedly some do. Undoubtedly others don't. Undoubtedly still others do
want it but only under certain conditions.

<snip>

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

Who knows? It might be neither of us. I'd certainly be very surprised to
find myself in a majority in *any* area where I actually had a choice
about which side I was on. Almost certainly most people, if asked, will
want garbage collection, but equally certainly most of them will *think*
you are asking whether they are in favour of the folk that bring the big
lorry round once a week (or once a fortnight, in more primitive areas).

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

[Richard Tobin]

In article <Hq******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

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

Almost everything expressed here is an opinion, and it's not
unreasonable to have an opinion about what most people want.

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

I think it will be clear to most regular readers that whether one
speaks for Richard Heathfield is unrelated to whether one speaks for
"most people". And this is not intended to express a preference
either way.

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

[santosh]

In article <23***************************@saipan.com>, cr88192
<cr*****@hotmail.comwrote on Monday 19 Nov 2007 4:44 pm:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Hq******************************@bt.com...

>Chris Dollin said:

<snip>

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

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

<snip>

What may be "an acceptable price" in some situations may not be
acceptable in others. Obviously C is still used to some extent on the
Desktop and hence programmers for that domain might consider a
Standardised GC as helping to "close the gap" between C and it's
more "Desktop ubiquitous" cousins. Many Desktop programmers don't
want/like to "go the whole hog" and use massive platforms like Java
and .NET. At the same time, some of them may wish for some of the
conveniences of those languages Standardised in C.

On the other hand it looks more likely that a GC would be Standardised
for C++ sooner than for C, so such developers might want to consider
C++. It provides all the "heavy ammunition" that C has, and also most
of the higher level language constructs and facilities of platforms
like Java and .NET. What it lacks, of course, is a massive standardised
code library (like in Java), but Boost can ease matters here.

[santosh]

In article <iL******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Monday 19 Nov 2007 5:00 pm:

cr88192 said:

<snip>

>if no C programmers wanted GC,

Undoubtedly some do. Undoubtedly others don't. Undoubtedly still
others do want it but only under certain conditions.

<snip>

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

Who knows? It might be neither of us. I'd certainly be very surprised
to find myself in a majority in *any* area where I actually had a
choice about which side I was on. Almost certainly most people, if
asked, will want garbage collection, but equally certainly most of
them will *think* you are asking whether they are in favour of the
folk that bring the big lorry round once a week (or once a fortnight,
in more primitive areas).

Funny. Around here it's every day, or rather night. Wonder which place
can go for a week without GC.

[Ben Bacarisse]

llothar <ll*****@web.dewrites:

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

Not in context. Several message into a sub-thread I am not going to
keep repeating all the well-known problems that GCs have with hidden
pointers. Clipped out like this, the statement is false. I meant I
was not pointing out a safety issue since it does not natter if these
pointers are hidden or not.

Maybe you should at least read the README.txt of Boehms GC before
talking about Garbage Collection.

I am aware of these problems -- in fact I posted about them the last
time this topic came up here.

--
Ben.

[Ben Bacarisse]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:

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

Yes, I've been called out for that quote already. I should have said
that *in this case* (the problem of freeing a block containing GC
pointers) conservative GC is safe. I just wanted to make it clear I
was not pointing out a correctness problem, just one of late
collection.

--
Ben.

[cr88192]

"santosh" <sa*********@gmail.comwrote in message
news:fh**********@registered.motzarella.org...

In article <23***************************@saipan.com>, cr88192
<cr*****@hotmail.comwrote on Monday 19 Nov 2007 4:44 pm:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Hq******************************@bt.com...

>>Chris Dollin said:

<snip>

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

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

<snip>

What may be "an acceptable price" in some situations may not be
acceptable in others. Obviously C is still used to some extent on the
Desktop and hence programmers for that domain might consider a
Standardised GC as helping to "close the gap" between C and it's
more "Desktop ubiquitous" cousins. Many Desktop programmers don't
want/like to "go the whole hog" and use massive platforms like Java
and .NET. At the same time, some of them may wish for some of the
conveniences of those languages Standardised in C.

it is my understanding that C and C++ still hold notable dominance on the
desktop as well (note, I lump then together here, because they are often
used in conjuction).

Java apps are a minority (actually, afaik, more people use Java on embedded
systems than on desktops).
C# has afaik as of yet not put a dent in much of anything much outside of
"MS and friends" land.

On the other hand it looks more likely that a GC would be Standardised
for C++ sooner than for C, so such developers might want to consider
C++. It provides all the "heavy ammunition" that C has, and also most
of the higher level language constructs and facilities of platforms
like Java and .NET. What it lacks, of course, is a massive standardised
code library (like in Java), but Boost can ease matters here.

yeah.

I actually still feel (oddly enough) that there are still some reasons for
preferring C over C++ (in general).

a few of these being:
my pre-existing codebase (many hundreds of kloc);
linkage issues (I mostly write "libraries" and not "frontends", where using
C++ in libraries somewhat complicates the task of maintaining proper
linkage with C-based frontends);
various other subtle technical reasons...

C is also a simpler language (good and important news for those of us who
write code-processing tools, such as auto-header tools and compilers, ...).

so, a few misc reasons...

[Philip Potter]

santosh wrote:

In article <iL******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrote on Monday 19 Nov 2007 5:00 pm:

>Who knows? It might be neither of us. I'd certainly be very surprised
to find myself in a majority in *any* area where I actually had a
choice about which side I was on. Almost certainly most people, if
asked, will want garbage collection, but equally certainly most of
them will *think* you are asking whether they are in favour of the
folk that bring the big lorry round once a week (or once a fortnight,
in more primitive areas).

Funny. Around here it's every day, or rather night. Wonder which place
can go for a week without GC.

Don't rub it in. Some UK councils have been trying to foist fortnightly
(biweekly) rubbish collection[1] on us...

Phil

[1] It's useful speaking British English here; for me there's no
ambiguity between "rubbish collection" and "garbage collection".

--
Philip Potter pgp <atdoc.ic.ac.uk

[cr88192]

"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:fh***********@pc-news.cogsci.ed.ac.uk...

In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:

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

worse yet, in my GC, all you have to do is put the pointer in unaligned
memory, and it will miss the reference.
this has not really been a problem in practice though...
(this makes the GC a lot faster, but leaves a few more cases where it can
potentially fail...).

in my case, I don't claim the GC is always "safe" or gueranteed to never
lose anything in various edge cases, only that it will generally work so
long as one doesn't try to do anything weird with it.
in my case, it is not a "malloc replacement" as such, rather, it is its own
API.
I use malloc where it makes sense, and GC where it makes sense, manually
freeing where it makes sense, and simply discarding memory where it makes
sense...

in my case, my practices generally seem to work...

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

[Charlton Wilbur]

>>>>"cr" == cr88192 <cr*****@hotmail.comwrites:

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

Of course. *Someone* wants garbage collection. At times, even *I*
want garbage collection. But you cannot go from that statement, which
you have provided adequate evidence for, to your original claim that
*most* programmers want garbage collection without a whole lot more
evidence than you have thus far provided.

I see enough benefits to having a memory management scheme that's
completely deterministic and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Chris Dollin]

Charlton Wilbur wrote:

I see enough benefits to having a memory management scheme that's
completely deterministic

[which malloc isn't]

and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

I imagine that they'd be much easier to implement, too, but then, I
have an erratic imagination.

--
Chris "Look, a unicorn! Oops. It's a princess." Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[dj3vande]

In article <fh**********@tadcaster.hpl.hp.com>,
Chris Dollin <ch**********@hp.comwrote:

>If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

I imagine that they'd be much easier to implement, too, but then, I
have an erratic imagination.

I would expect implementing namespaces to be nearly trivial on most
implementations; the implementation would simply need to mangle
namespace-qualified names (say "namespace::symbol", borrowing the C++
namespace syntax) into names containing a character or sequence of
characters not permitted by C but acceptable to the platform's linker
("namespace$symbol" would probably be a good choice on many
platforms).

Implementing namespaces without breaking the nearly-trivial binary
interface that makes C the language of choice for implementing
low-level interfaces for many higher-level languages would be a more
difficult problem, but would probably still be significantly simpler
than specifying and implementing C++-style name mangling. (Whether
it's simple enough to be worth doing is another question, and I suspect
the answer is "no".)

(This would also mean that C wouldn't see a std:: namespace anytime
soon, even though that's an obvious thing that would make life
significantly easier for both implementors and programmers in a lot of
cases if it were reasonable to do it.)
dave

[jacob navia]

Charlton Wilbur wrote:

>>>>>"cr" == cr88192 <cr*****@hotmail.comwrites:

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

Of course. *Someone* wants garbage collection. At times, even *I*
want garbage collection. But you cannot go from that statement, which
you have provided adequate evidence for, to your original claim that
*most* programmers want garbage collection without a whole lot more
evidence than you have thus far provided.

I see enough benefits to having a memory management scheme that's
completely deterministic and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

Charlton

This depends on the application but it is obviously not true
for the type of applications I have ported (GUI programs in C, debugger,
IDE, make utility) The ONLY change I did was

#define malloc(a) GC_malloc(a)

#define free(a)

Of course I do NOT write pointers into disk files and expect them
there to be read after the machine is turned off :-)

Neither do I do XORing of pointers, etc etc.

Normal applications like 99.9999 C applications that can use the GC
without any problems!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Chris Dollin wrote:

Charlton Wilbur wrote:

>I see enough benefits to having a memory management scheme that's
completely deterministic

[which malloc isn't]

>and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

I imagine that they'd be much easier to implement, too, but then, I
have an erratic imagination.

What is the advantage of namespaces compared to the prefixing of
identifiers we use now?

The GC gives me advantages right now, but namespaces?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

Chris Dollin <ch**********@hp.comwrites:

Charlton Wilbur wrote:

>I see enough benefits to having a memory management scheme that's
completely deterministic

[which malloc isn't]

>and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Ack. If I added my own, I'd have C+exceptions or C+simple templates.

Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

For the same reasons.

--
Ben.

[Keith Thompson]

jacob navia wrote:
[...]

This depends on the application but it is obviously not true
for the type of applications I have ported (GUI programs in C, debugger,
IDE, make utility) The ONLY change I did was

#define malloc(a) GC_malloc(a)

#define free(a)

Of course I do NOT write pointers into disk files and expect them
there to be read after the machine is turned off :-)

Neither do I do XORing of pointers, etc etc.

Ok, that's great, I'm glad it works for you.

Note that what you're describing (replacing malloc with GC_malloc, and making
free a no-op) is exactly what I had (incorrectly?) assumed you were talking
about. Your response was sarcasm and abuse. Admittedly you're now talking
about doing it at the application level rather than at the implementation level
(I think).

Normal applications like 99.9999 C applications that can use the GC
without any problems!

Is 99.9999 intended to be an exaggeration, or do you really think the number is
that high (I assume it's a percentage)?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Ben Pfaff wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

>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"?

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

And without eating up processing time, or code space, or requiring
extra steps in writing, or ... Of course it must also meet all
requirements of standard ISO C, and not impact any other practices
whatsoever. I suspect 'magic' is the right adjective.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

James Kuyper wrote:

>

.... snip ...

>
And, whatever you do, don't refer to "must people" when you mean
"most people", as cr88192 did. :-)

Most people must make much fuss about minimum code. :-)

or

Must people make much more fuss about code minima.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

Keith Thompson wrote:

jacob navia wrote:
[...]

>This depends on the application but it is obviously not true
for the type of applications I have ported (GUI programs in C, debugger,
IDE, make utility) The ONLY change I did was

#define malloc(a) GC_malloc(a)

#define free(a)

Of course I do NOT write pointers into disk files and expect them
there to be read after the machine is turned off :-)

Neither do I do XORing of pointers, etc etc.

Ok, that's great, I'm glad it works for you.

Note that what you're describing (replacing malloc with GC_malloc, and
making free a no-op) is exactly what I had (incorrectly?) assumed you
were talking about. Your response was sarcasm and abuse. Admittedly
you're now talking about doing it at the application level rather than
at the implementation level (I think).

Of course. Imagine if I would do it at the compiler level,
people could no longer use malloc!

That would make it impossible to use third party libraries
with that code. It just can't be done. At the application
level I could do it since my IDE doesn't use any
third party libraries and I know that!

>Normal applications like 99.9999 C applications that can use the GC
without any problems!

Is 99.9999 intended to be an exaggeration, or do you really think the
number is that high (I assume it's a percentage)?

How many applications you have seen that write pointers into
disk files, xor pointers or do such kind of nonsense?

I have never seen one.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Philip Potter]

jacob navia wrote:

Keith Thompson wrote:

>jacob navia wrote:

>>Normal applications like 99.9999 C applications that can use the GC
without any problems!

Is 99.9999 intended to be an exaggeration, or do you really think the
number is that high (I assume it's a percentage)?

How many applications you have seen that write pointers into
disk files, xor pointers or do such kind of nonsense?

I have never seen one.

Jacob, don't quote figures you fabricated then use anecdotal evidence to
back them up. That's just not science. Unless you have done proper
research across a wide cross-section of application domains and coding
groups, the fact that you've never seen one means precisely zilch. (I
have seen precisely zero uses of ptrdiff_t - I guess it doesn't exist,
right?)

It doesn't matter how many people can use GC successfully, it matters
how many /can't/ - and because the sort of problems that we're talking
about, the errors are of the intermittent runtime difficult-to-debug
variety. If I can't be absolutely sure that I can use your GC on my
standard C program, I won't bother. I'd have to go through the entire
program to make sure it doesn't do 'clever' stuff with pointers; or
start a new C-with-GC program from scratch (but I wouldn't do that
because I'd be stuck with one compiler on one platform).

And don't try to tar this post as 'polemic' either. It's nothing of the
sort.

Phil

[Mark McIntyre]

jacob navia wrote:

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.

You know, such stupid remarks don't exactly make people take you seriously.

Of /course/ people consider the opinion of highly experienced and
respected contributors to be important. Naturally, they consider the
output of less respected individuals, such as myself, to be of less worth.

[Chris Dollin]

Ben Bacarisse wrote:

Chris Dollin <ch**********@hp.comwrites:

>Charlton Wilbur wrote:

>>I see enough benefits to having a memory management scheme that's
completely deterministic

[which malloc isn't]

>>and completely in the hands of the programmer
that I don't want to see it go away as an option. And (as has been
pointed out) the semantics of C make it very difficult to use a
garbage collector that's implemented as a library; I think the
effort's better spent elsewhere.

If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Ack. If I added my own, I'd have C+exceptions or C+simple templates.

>Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

For the same reasons.

I /think/ that adding exceptions would introduce run-time overheads: I
could of course be wrong.

--
Chris "tempted to quote Galen" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Chris Dollin]

jacob navia wrote:

What is the advantage of namespaces compared to the prefixing of
identifiers we use now?

We wouldn't have to prefix the identifiers, or rely on others doing
so, or rely on them avoiding the prefix /we/ though was a good one,
or consume source space with repeated prefixes.

Rather than guessing at prefixing conventions, tools would know
how to read/manage/write code components that used namespaces.

That may not be an advantage for you.

--
Chris "eg" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[jacob navia]

Chris Dollin wrote:

jacob navia wrote:

>What is the advantage of namespaces compared to the prefixing of
identifiers we use now?

We wouldn't have to prefix the identifiers, or rely on others doing
so, or rely on them avoiding the prefix /we/ though was a good one,
or consume source space with repeated prefixes.

We would have to rely that others do not prefix other workspaces
with the same name as we do to do other stuff. There are many graphic
libraries and graphics::DrawPoint(); can be used by many of them.

We would have to cope with the fact that libraries compiled with
different compilers use different name spaces schemes and we
can't link with them...

This change doesn't look good for being able to use third party
libraries compiled with a different compiler...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Philip Potter wrote:

It doesn't matter how many people can use GC successfully, it matters
how many /can't/ - and because the sort of problems that we're talking
about, the errors are of the intermittent runtime difficult-to-debug
variety. If I can't be absolutely sure that I can use your GC on my
standard C program, I won't bother.

Do not bother. Go on debugging malloc/free problems that are of the
same "intermittent runtime difficult to debug variety".

I'd have to go through the entire
program to make sure it doesn't do 'clever' stuff with pointers;

???

You XOR pointers?

You write pointer to files?

or
start a new C-with-GC program from scratch (but I wouldn't do that
because I'd be stuck with one compiler on one platform).

Mr Boehm's GC runs with:

gcc/hp unix/msvc/lcc-win32/ and many other platforms.

And don't try to tar this post as 'polemic' either. It's nothing of the
sort.

Never said otherwise.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Chris Dollin]

jacob navia wrote:

Chris Dollin wrote:

>jacob navia wrote:

>>What is the advantage of namespaces compared to the prefixing of
identifiers we use now?

We wouldn't have to prefix the identifiers, or rely on others doing
so, or rely on them avoiding the prefix /we/ though was a good one,
or consume source space with repeated prefixes.

We would have to rely that others do not prefix other workspaces
with the same name as we do to do other stuff.

That's pretty much a solved problem.

We would have to cope with the fact that libraries compiled with
different compilers use different name spaces schemes and we
can't link with them...

"Doctor! Doctor! It will hurt if I do this!"

This change doesn't look good for being able to use third party
libraries compiled with a different compiler...

Darwin.

--
Chris "not all problems need technical solutions" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Philip Potter]

jacob navia wrote:

Philip Potter wrote:

>It doesn't matter how many people can use GC successfully, it matters
how many /can't/ - and because the sort of problems that we're talking
about, the errors are of the intermittent runtime difficult-to-debug
variety. If I can't be absolutely sure that I can use your GC on my
standard C program, I won't bother.

Do not bother. Go on debugging malloc/free problems that are of the
same "intermittent runtime difficult to debug variety".

Thank you, I will.

>I'd have to go through the entire program to make sure it doesn't do
'clever' stuff with pointers;

???

You XOR pointers?

You write pointer to files?

It doesn't matter what /I/ do, but what the previous programmers on the
same project did; and we all know it's a mistake to make assumptions
about such people.

(A side point: does your GC count a pointer to the middle of an array as
a reference? If not, that's another (much more common) case where memory
could be erroneously freed.)

>or start a new C-with-GC program from scratch (but I wouldn't do that
because I'd be stuck with one compiler on one platform).

Mr Boehm's GC runs with:

gcc/hp unix/msvc/lcc-win32/ and many other platforms.

Fair enough.

>And don't try to tar this post as 'polemic' either. It's nothing of
the sort.

Never said otherwise.

Good. You've stung me with it before which I wanted to preempt it this time.

[Richard Tobin]

In article <fh**********@tadcaster.hpl.hp.com>,
Chris Dollin <ch**********@hp.comwrote:

>I /think/ that adding exceptions would introduce run-time overheads: I
could of course be wrong.

Java allegedly has exceptions with no run-time overhead: the range of
instructions covered by a "try" is recorded in the symbol table, and
only when an exception occurs is work done to determine what happens.

No doubt this has implications for optimisation, at least.

-- Richard

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

[Ben Bacarisse]

jacob navia <ja***@nospam.orgwrites:

Chris Dollin wrote:

>jacob navia wrote:

>>What is the advantage of namespaces compared to the prefixing of
identifiers we use now?

We wouldn't have to prefix the identifiers, or rely on others doing
so, or rely on them avoiding the prefix /we/ though was a good one,
or consume source space with repeated prefixes.

We would have to rely that others do not prefix other workspaces
with the same name as we do to do other stuff. There are many graphic
libraries and graphics::DrawPoint(); can be used by many of them.

No. These are all problems with plain text prefixes (your preference)
but become non-problems with namespaces. By putting the #include
"graphics.h" in a namespace {} clause one can either add or change the
"prefix" to work round naming conflicts.

--
Ben.

[Ben Bacarisse]

Chris Dollin <ch**********@hp.comwrites:

Ben Bacarisse wrote:

>Chris Dollin <ch**********@hp.comwrites:

<snip>

>>If someone offered me the choice: C-with-GC /or/ C-with-namespaces, for
relatively sane versions of namespaces, I'd pick C-with-namespaces in
an instant.

Ack. If I added my own, I'd have C+exceptions or C+simple templates.

>>Why?

Pretty much any C program could usefully use namespaces /right now/.
They impose no run-time overheads. Their specification and implementation
are much less likely to encounter intractable legacy thickets.

For the same reasons.

I /think/ that adding exceptions would introduce run-time overheads: I
could of course be wrong.

If you mean a cost incurred by program that don't even use them (just
in case) than that would, in my view rule it out, because of C's "you
don't pay for what you don't use" idea. However, I don't think that
is the case but then I, too, could be wrong!

--
Ben.