Garbage collection problems

[Philip Potter]

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]

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]

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

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.

 

[jacob navia]

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:rawPoint(); 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]

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.

 

[Philip Potter]

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

Thank you, I will.

???

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

Mr Boehm's GC runs with:

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

Fair enough.

Never said otherwise.

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

 

[Chris Dollin]

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.

 

[Richard Tobin]

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

 

[Ben Bacarisse]

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:rawPoint(); 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 Bacarisse]

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!

 

[jacob navia]

jacob navia wrote:

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.

I have never seen a program that XOR pointers.
Neither one that writes pointers to disk, then reads them back.
Sorry, I am programming in C since relatively few years. I
started around 1984.

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

It counts as a reference of course.

 

[jacob navia]

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.

lcc-win implements try/catch since 1997.
Only programs that use try/catch are affected, and then, only those
functions that use try/catch are affected. Other functions
are NOT affected at all.

There is a common cost (of around a few dozens instructions)
by establishing a try/catch around the "main" function. This
is completely negligible in a program that normally executes
millions of instructions.

This implementation of try/catch relies on the support existing
under the windows system for this, and in the C language that
doesn't need destructors. Other languages/Operating systems may
do less well.

Specifically in C++ all programs pay this price. Under linux,
for instance, gcc generates huge tables of data to support
the exception handling mechanism. This makes for code bloat
(data bloat in this case)

 

[Philip Potter]

I have never seen a program that XOR pointers.
Neither one that writes pointers to disk, then reads them back.
Sorry, I am programming in C since relatively few years. I
started around 1984.

I assume you mean "I have been programming in C for relatively few
years" and that you are being ironic (ie you *really* mean "I have been
programming in C for relatively many years").

(Normally I don't correct grammar, but in this case I'm not sure what
you mean and I want to be clear. I hope you don't take offense!)

Anyway, I'd like to reiterate:

It's not enough that *you* haven't seen it, even if you *have* been
coding since 1984.

It counts as a reference of course.

That's good then

 

[borkhuis]

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

I never had any use for a GC, as probably most developers working on
embedded and/or real time systems. Anything that causes unknown
overhead makes my think a number of times before including it, and
something that is touching memory

When I write my program I think about what areas I need to allocate,
and make sure they are allocated before I my application is started.
And there is no dynamic allocating and freeing memory, as most
embedded developers would agree to.

And as most devices used in the world are embedded devices (which run
usually months or years without problems (and without the need for GC)
I would suggest that you change that number from 99.something to
9.something, which is probably closer to the percentage of software
that can use a GC.

Kind regards,
Johan Borkhuis

 

[Old Wolf]

after all, if no one really wanted GC, then Java and C# would leave them
out,

non-sequitur. Proprietary languages include all sorts of crap
that a few people want, and then try to convice everybody
that they all need to use the feature (and thus get locked in).

 

[santosh]

I have never seen a program that XOR pointers.
Neither one that writes pointers to disk, then reads them back.
Sorry, I am programming in C since relatively few years. I
started around 1984.

I guess that intentionally obfuscated (for whatever reasons) programs
might XOR their pointers.

Again I'm guessing that some very old programs, designed to run on
highly memory constrained systems, might write out their state to disk
files, from time to time. Programs (old or recent) that implement some
form of crash recovery or hibernation might also do this.

A GC might not really be suitable for such programs anyway. I don't see
how a Standardised GC will break such programs if it's made an optional
element, much like the intN_t types and bool today.

<snip>

 

[santosh]

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.

Specifically in C++ all programs pay this price.

<snip>

Is this so? I thought C++ preserved the C spirit of incurring overhead
for only what you actually use?

 

[Chris Dollin]

If you mean a cost incurred by program that don't even use them (just
in case)

If an entire program doesn't use any EH, then you'd expect the overhead to
be minimal.

It might not be zero, unless there's a way to tell the compiler to
compile compilation units assuming that they'll be used in an EH-free
program: it's possible that code that might execute in an EH
environment might suffer optimisation penalties. On the other hand,
I don't see that they'd be much different from any penalties already
paid for set/longjmp.

I seem to recall that earlier C++ compilers had this sort of EH-controlling
switch. (Not having using C++ in anger recently, I don't know about
current C++ compilers, not even specifically g++.)

 

[Chris Dollin]

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.

The instruction-ranges aren't just in the compiler symbol table; they're
in the class-file and subsequently in the tables associated with the
method.

I would count those tables as run-time overhead, but I agree it wasn't
obvious I meant space as well as time.

No doubt this has implications for optimisation, at least.

Indeed. (As I said elsethread, WRT C it isn't clear [to me] whether that
would be additional to the implications from set/longjmp.)

Any [other] C compiler-writers around to comment?