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

[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**********@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.

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::DrawP oint(); 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 "intermitte nt 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 "intermitte nt 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**********@t adcaster.hpl.hp .com>,
Chris Dollin <ch**********@h p.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

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

[Ben Bacarisse]

jacob navia <ja***@nospam.o rgwrites:

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::DrawP oint(); 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**********@h p.comwrites:

Ben Bacarisse wrote:

>Chris Dollin <ch**********@h p.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.