Garbage collection problems

[Richard Tobin]

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

[/QUOTE]

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

 

[santosh]

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.

 

[Richard Heathfield]

cr88192 said:

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.

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.

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

 

[santosh]

cr88192 said:


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



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]

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

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.

 

[cr88192]

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

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

 

[cr88192]

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

 

[James Kuyper]

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.[/QUOTE]

Actually, yes it is. Without a decent sample size, conclusions about
"most people" are simply unjustified. If your sample size is "everyone I
know", it's probably too small by at least a couple of orders of
magnitude. Say something you can actually vouch for being true, like
"most programmers I know". Don't attempt to give your evidence more
weight than it actually deserves by conflating "most of the programmers
I know" with "most people".

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

 

[Charlton Wilbur]

cr> after all, if no one really wanted GC, then Java and C# would
cr> leave them out, and things like Boehm, and the endless other
cr> custom 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

 

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

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.

 

[dj3vande]

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]

cr> after all, if no one really wanted GC, then Java and C# would
cr> leave them out, and things like Boehm, and the endless other
cr> custom 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]

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?

 

[Ben Bacarisse]

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.

 

[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)?

 

[CBFalconer]

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.

 

[CBFalconer]

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

 

[jacob navia]

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!

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.