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

[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**********@t adcaster.hpl.hp .com>,
Chris Dollin <ch**********@h p.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::sym bol", 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$sym bol" 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*****@hotmai l.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**********@h p.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_Keit h) 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.in validwrites:

>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