Garbage collection

[jacob navia]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple
explanation for this. Languages without automated garbage collection are
getting out of fashion. The chance of running into all kinds of memory
problems is gradually outweighing the performance penalty you have to
pay for garbage collection.
<end quote>

lcc-win has been distributing a GC since 2004.

It really helps.

 

[cr88192]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple explanation
for this. Languages without automated garbage collection are getting out
of fashion. The chance of running into all kinds of memory problems is
gradually outweighing the performance penalty you have to pay for garbage
collection.
<end quote>

lcc-win has been distributing a GC since 2004.

It really helps.

I agree...

I have also been using garbage collection in my projects for years with good
success...
I also face people who condemn both garbage collection and C, but I really
like C personally (I am less of a fan of Java personally, even if it has
gained a lot of ground...).

C# may also become a big player, and may in time overpower Java (there are
variables though, I suspect .NET being both a gain and a potential
hinderance at this point in time).

C will likely remain around for a while, but the high-point for C++ may be
starting to pass (C++ is a heavy beast, and losing some of its major selling
points to other languages, may start to fall into disuse much faster than C
does...).

 

[Yunzhong]

I don't see C dying out any time soon. The problem with automatic
garbage collection is not just in performance penalty, but that it
introduces uncertainty to the code. It becomes difficult to predict at
what time the garbage collector will start running. In some cases this
behavior simply cannot be tolerated.

 

[jacob navia]

I don't see C dying out any time soon. The problem with automatic
garbage collection is not just in performance penalty, but that it
introduces uncertainty to the code. It becomes difficult to predict at
what time the garbage collector will start running. In some cases this
behavior simply cannot be tolerated.

In Boehm's GC it will start ONLY when you call malloc().
If you do not call malloc() nothing can happen...

 

[user923005]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

Who's Paul Jansen?

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple
explanation for this. Languages without automated garbage collection are
getting out of fashion. The chance of running into all kinds of memory
problems is gradually outweighing the performance penalty you have to
pay for garbage collection.
<end quote>

lcc-win has been distributing a GC since 2004.

It really helps.

Is lcc-win outselling Microsoft or Intel's compilers?

I guess that most C work is at the embedded level today. I doubt if
we will have garbage collectors running in our toasters any time soon.

 

[Richard]

That's why the toast crumbs keep accumulating at the bottom.

Heh. That's funny - no garbage collection. Good one.

 

[santosh]

In what ways does that implementation violate the standard?

My bet is that it will incorrectly free pieces of allocated memory
when the only references to that memory are in a file (written by
that process and later read back in by the same process). If lcc-win
actually handles this, its performance likely sucks if it has to
scan gigabyte (or worse, terabyte) files for pointer references.
I think the standard also allows, under the right circumstances,
for pointers to be *encrypted*, then stored in a file, and later
read back, decrypted, and used.

Oh, yes, to count as GC, it has to occasionally actually free
something eligible to be freed.

I don't consider this to be a fatal flaw for GC in general or this
implementation in particular, as storing pointers in files is
relatively unusual. But a standards-compliant GC has to deal with
it.

As GC hasn't been defined by the standard yet, we can't say. For all we
know WG14 might decide to excuse GC from scanning for pointers in files
and similar stuff. Right now using a GC is non-conforming simply
because the standard attempts no definition for it.

 

[Keith Thompson]

As GC hasn't been defined by the standard yet, we can't say. For all we
know WG14 might decide to excuse GC from scanning for pointers in files
and similar stuff. Right now using a GC is non-conforming simply
because the standard attempts no definition for it.

But a given GC implementation might cause a C implementation that uses
it to become non-conforming because it causes that implementation to
violate the requirements that the standard *does* define.

For example, it's perfectly legal to take a pointer object, break its
representation down into bytes, and store those bytes separately, then
erase the pointer object's value. You can later reconstitute the
pointer value from the bytes and use it. A typical GC implementation,
such as Boehm's, will detect that there is no pointer currently in
memory that refers to the referenced block of memory, and collect it.

I'm not claiming that that this is an insurmountable problem. You're
free to use an almost-but-not-quite-conforming C implementation if
it's useful to do so, and if the actions that would expose the
nonconformance are rare and easy to avoid. And if GC were
incorporated into a future C standard, the rules would probably be
changed to allow for this kind of thing (by rendering the behavior of
breaking down and reconstituting a pointer like this undefined), at
least in programs for which GC is enabled.

(I do not give permission to quote this article, or any other article
I post to Usenet, without attribution.)

 

[Keith Thompson]

If you need GC, well yes, it would help out a whole lot indeed. As
long as its not mandatory, I see absolutely nothing wrong with
including a full-blown GC in your compiler package.

I also see nothing wrong with it. However, users need to be aware
that if they write code that depends on GC, they're going to have
problems if they want to use it with an implementation that doesn't
support GC. This is a problem with any extension, no matter how
useful.

(I think it's possible to use the Boehm GC with other compilers. I
don't know how difficult it is.)

 

[jacob navia]

But a given GC implementation might cause a C implementation that uses
it to become non-conforming because it causes that implementation to
violate the requirements that the standard *does* define.

For example, it's perfectly legal to take a pointer object, break its
representation down into bytes, and store those bytes separately, then
erase the pointer object's value. You can later reconstitute the
pointer value from the bytes and use it. A typical GC implementation,
such as Boehm's, will detect that there is no pointer currently in
memory that refers to the referenced block of memory, and collect it.

Then, there is only ONE solution for you and all people like you:

DO NOT USE A GC.

Then, you will happily be able to xor your pointers, store it in files,
whatever.

For the other people that do care about memory management, they can go
on using the GC.

The only reaction from the "regulars" are this kind of very practical
arguments.

Nobody is forbidding anyone to store pointers in files. You can't store
only those that the GC uses. Other pointers can be stored in files
at will, since malloc is still available!

This is typical of their arguments: No substance, just form. There
could be a pointer stored in a file and the standard says at paragraph
blah... blah... blah...

The practical advantages of a GC for a programming language, the pros
and cons... they do not care

 

[Richard Tobin]

Then, there is only ONE solution for you and all people like you:

DO NOT USE A GC.

Then, you will happily be able to xor your pointers, store it in files,
whatever.

For the other people that do care about memory management, they can go
on using the GC.

Be reasonable Jacob. You deleted the rest of Keith's article, where
he essentially agrees with you that this problem could be overcome
by changing C's rules when GC is enabled. You could perfectly well
have followed up with more discussion of this without flaming him.

-- Richard

 

[Paul Hsieh]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple
explanation for this. Languages without automated garbage collection are
getting out of fashion. The chance of running into all kinds of memory
problems is gradually outweighing the performance penalty you have to
pay for garbage collection.
<end quote>

lcc-win has been distributing a GC since 2004.

It really helps.

While I understand what you are doing, it always saddens me that we
are presented with this false dichotomy. Either we have this painful
C interface which is precise and fast, but dangerous and cumbersome or
we have garbage collection which is slow and opaque, but safe and
easy.

GC has the disadvantage that you don't *know* when you are going to
free your memory. In C we have the disadvantage that we don't *know*
what memory we have outstanding/available except by working it out
from the model of our program. C++ helps a little with the RAII
concept, but you can still leak quite easily (and in ways that are
insanely hard to debug.)

If C was merely augmented with total memory consumption statistic
functions and/or heap walking mechanisms and heap checking, all the
main complaints about C's memory management problems would be
immediately addressed. The language itself would then be useful in
discovering problems in code -- even the most complicated structures
would be fairly approachable, because the ability to debug would
always be present.

Alas people don't see it that way. The problem is that people who
remain loyal to C are too quick to defend C's method without even
acknowledging its weaknesses. They are essentially arguing that in
order to support better memory management, you have to go to garbage
collection and give up the rest of the C language while you are at
it. Its just so infuriating to me.

"Why not have GC and malloc/free at the same time" is at least an
acknowledgment that there are other ways of addressing the issue. The
way people obsess over the fact that its impossible to do perfect GC
in C due to some strange pointer obfuscation issue is so telling of
how badly these people miss the point (the chances that you mess up
your memory management in your code is enormously higher than the
chances that you would even consider putting pointer obfuscation in
your program design).

I personally would prefer to go in the direction of improving the
precise memory control model myself. But the ultimate solution (which
may be too hard to implement; I don't know) is to have an augmented
precise memory control interface *in addition* to a directly
compatible GC system (i.e., you would need to support realloc() and
free() on the GC allocated memory in a meaningful way.) A system like
that would offer such an enormous value add; but I don't know that it
could be adopted by the standards committee.

 

[Keith Thompson]

Then, there is only ONE solution for you and all people like you:

DO NOT USE A GC.

Then, you will happily be able to xor your pointers, store it in files,
whatever.

For the other people that do care about memory management, they can go
on using the GC.

The only reaction from the "regulars" are this kind of very practical
arguments.

Nobody is forbidding anyone to store pointers in files. You can't store
only those that the GC uses. Other pointers can be stored in files
at will, since malloc is still available!

This is typical of their arguments: No substance, just form. There
could be a pointer stored in a file and the standard says at paragraph
blah... blah... blah...

The practical advantages of a GC for a programming language, the pros
and cons... they do not care

jacob, I can only assume that you didn't bother to read what I
actually wrote before you responded.

I did not argue against GC. I pointed out a possible problem that
might be associated with the use of GC, particularly in the context of
conformance to the C standard.

Here's part of what I wrote that you didn't quote in your followup:

| I'm not claiming that that this is an insurmountable problem. You're
| free to use an almost-but-not-quite-conforming C implementation if
| it's useful to do so, and if the actions that would expose the
| nonconformance are rare and easy to avoid. And if GC were
| incorporated into a future C standard, the rules would probably be
| changed to allow for this kind of thing (by rendering the behavior of
| breaking down and reconstituting a pointer like this undefined), at
| least in programs for which GC is enabled.

The C standard was not written with GC in mind. You might want to
argue that it should have been, or that it should be modified so that
it allows for GC, but it's a fact that the current standard doesn't
allow for GC. Because of this, it's not at all surprising that there
might be some corner cases where GC and C standard conformance might
collide.

I pointed out a *minor* issue that *might* cause a problem in some
rare cases. I also mentioned how to avoid that issue. And somehow
you interpreted this as an attack on GC and/or on you personally.

I. Did. Not. Argue. Against. GC.

Please re-read what I actually wrote however many times it takes until
you understand this.

I use languages other than C that depend on built-in garbage
collection, and it's extremely useful. I haven't had an opportunity
to use a C implementation that provides GC, so I can't really comment
on how useful it would be in that context.

 

[Flash Gordon]

William Ahern wrote, On 25/04/08 20:33:

When people merely say "embedded", I think it confuses the issue.

True and not just for the reasons you give. Sometimes an "embedded"
processor turns out to be a full blown computer running either Linux or
some version of Windows.

The places where C continues to be used, and will continue to be used, are
places where the problem is very well defined, and the solution amenable to
a fixed interface. This happens to be the case for embedded hardware
products, as well as for many elements of more general purpose computing
platforms: SQL databases, libraries or applications implementing

And I think that when people characterize the C community as "mostly
embedded developers", they fall into the trap of excusing or explaining a
supposed shift; but I don't see a shift in C usage much at all.

There are also applications which are currently written in C where as
bits need to be updated they are replaced with code written in other
languages. Thus in at least some areas (at the very least in some
companies) the number of lines of C code being used is decreasing as an
absolute not just relative amount.

All that's happening is that there are myriad new _types_ of applications,
many of which C is not well suited for. The old _types_ are still there, and
usage is growing in absolute terms. There's no need for a bunker mentality.

I agree there is no need for a bunker mentality. Other languages which
are older than me are still alive and well (even if not used as much)
and I'm sure that there will be enough C work around to keep all those
who both want to be C programmers and have the aptitude/attitude to be C
programmers busy for a long time to come.

 

[jacob navia]

While I understand what you are doing, it always saddens me that we
are presented with this false dichotomy. Either we have this painful
C interface which is precise and fast, but dangerous and cumbersome or
we have garbage collection which is slow and opaque, but safe and
easy.

Surely my intention wasn't to make an alternative out of GC or
not GC! There are many other possibilities.

GC has the disadvantage that you don't *know* when you are going to
free your memory.

I see it precisely as an advantage. I do not know and I do not want
to know it precisely. I want that the machine keeps track of it and
not me. In *some* cases you want to know when you free it, for instance
if you have allocated a huge block and want to release it immediately to
avoid a GC. In that cases you call GC_free() that releases the memory
block immediately.


In C we have the disadvantage that we don't *know*

what memory we have outstanding/available except by working it out
from the model of our program. C++ helps a little with the RAII
concept, but you can still leak quite easily (and in ways that are
insanely hard to debug.)

Like all C++

If C was merely augmented with total memory consumption statistic
functions and/or heap walking mechanisms and heap checking, all the
main complaints about C's memory management problems would be
immediately addressed. The language itself would then be useful in
discovering problems in code -- even the most complicated structures
would be fairly approachable, because the ability to debug would
always be present.

C programmers do not need debuggers and can debug programs by phone
without the source.

Dixit...

This attitude about debugging (debugging is only for stupid people that
have bugs. I do not have any bugs since I am the best programmer in the
world) permeates all the philosophy of the language, and memory
management is no exception.

No care is given to the debugging features of malloc/free at all.

Alas people don't see it that way. The problem is that people who
remain loyal to C are too quick to defend C's method without even
acknowledging its weaknesses.

My language right or wrong!

They are essentially arguing that in
order to support better memory management, you have to go to garbage
collection and give up the rest of the C language while you are at
it. Its just so infuriating to me.

GC is one solution. Your proposal would be another. I do not see why you
think it is an either/or thing.

"Why not have GC and malloc/free at the same time" is at least an
acknowledgment that there are other ways of addressing the issue.

The malloc/free system is still there of course!

I personally would prefer to go in the direction of improving the
precise memory control model myself. But the ultimate solution (which
may be too hard to implement; I don't know) is to have an augmented
precise memory control interface *in addition* to a directly
compatible GC system (i.e., you would need to support realloc() and
free() on the GC allocated memory in a meaningful way.) A system like
that would offer such an enormous value add; but I don't know that it
could be adopted by the standards committee.

I can't implement that. I do not have the time. If there was an effort
where I could collaborate I would, but I can't do it alone.

 

[jacob navia]

I did not argue against GC. I pointed out a possible problem that
might be associated with the use of GC, particularly in the context of
conformance to the C standard.

Please, that stuff appears every time I mention the GC here.

"I *could* store pointers in disk and read it later, so the GC
is not conforming"

You know that this has no practical significance at all. Since a
conforming program that stores pointers in the disk is using
malloc/free and that system is still available, those programs
would CONTINUE TO RUN!

The only case where the program would NOT run is if they use the GC
allocated pointers and put them in the disk!


But this is the same as saying that

I stored the socket descriptor in the disk and then, next day, when I
turned on the machine the network connection would not work...

Don't you think that it would be much more substantial to address the
issues that the GC poses in a substantive way?

Or the issues about the debugging support that Paul Hsie proposes?

That would be more interesting that the ethernal "GC-and-storing
pointers in the disk" discussion!

 

[cr88192]

I don't see C dying out any time soon. The problem with automatic
garbage collection is not just in performance penalty, but that it
introduces uncertainty to the code. It becomes difficult to predict at
what time the garbage collector will start running. In some cases this
behavior simply cannot be tolerated.

I wasn't saying it would die out "soon". what I wrote about could easily
take 10 or 15 years to play out at the current rates...


but, my speculation is like this:
C will fall out of favor for mainstream app development (it already largely
has), but will likely retain a stronghold in low-level systems, namely:
embedded systems, OS-kernels, drivers, domain-specific languages (ok, likely
C-variants), libraries, VMs, ...

meanwhile, C++ is currently at its high-point, and I will guess will start
to decline at a faster rate than C (in 15 years, it may have largely fallen
into disuse). a partial reason for this being a "high cost of maintainence"
(for both code and implementations, the language less likely to overtake C's
strongholds, it falls into decline).

Java is likely to overtake C++, and for a while become the dominant language
for app development.


C# is likely to grow at a faster rate than Java, at some point (say, 5-10
years) overtaking both, however. in this time, to make a guess, .NET will
either be abandoned or heavily mutated (for example, .GNU, which in time may
likely mutate in a divergent path).

at the current rates, in this time period, Windows will also fall behind,
with most likely the mainstream OS being Linux (thus, C# would become the
dominant language, on Linux...).

however, this is predicated on the language and apps being able to
effectively make the transition (the fall of Windows majorly hurting, but
not likely killing, the language).


and in the course of all this, new languages emerge that further begin to
overtake the current generation (IMO, there will never be an "ultimate
language", only new ones, most changing what they will, but otherwise being
very conservative).

the mainstream language in 20 years could very well by a hybrid of C#,
JavaScript, and features from many other languages...

by this time, I also expect notable mutations in terms of kernel
architecture and filesystems, us likely facing the demise of both processes
and heirarchical filesystems... Linux either facing replacement, or being
internally restructured into something almost unrecognizable...

and so on...


as noted, this is mostly all just speculation here...

 

[user923005]

I wasn't saying it would die out "soon". what I wrote about could easily
take 10 or 15 years to play out at the current rates...

but, my speculation is like this:
C will fall out of favor for mainstream app development (it already largely
has), but will likely retain a stronghold in low-level systems, namely:
embedded systems, OS-kernels, drivers, domain-specific languages (ok, likely
C-variants), libraries, VMs, ...

meanwhile, C++ is currently at its high-point, and I will guess will start
to decline at a faster rate than C (in 15 years, it may have largely fallen
into disuse). a partial reason for this being a "high cost of maintainence"
(for both code and implementations, the language less likely to overtake C's
strongholds, it falls into decline).

Java is likely to overtake C++, and for a while become the dominant language
for app development.

C# is likely to grow at a faster rate than Java, at some point (say, 5-10
years) overtaking both, however. in this time, to make a guess, .NET will
either be abandoned or heavily mutated (for example, .GNU, which in time may
likely mutate in a divergent path).

at the current rates, in this time period, Windows will also fall behind,
with most likely the mainstream OS being Linux (thus, C# would become the
dominant language, on Linux...).

however, this is predicated on the language and apps being able to
effectively make the transition (the fall of Windows majorly hurting, but
not likely killing, the language).

and in the course of all this, new languages emerge that further begin to
overtake the current generation (IMO, there will never be an "ultimate
language", only new ones, most changing what they will, but otherwise being
very conservative).

the mainstream language in 20 years could very well by a hybrid of C#,
JavaScript, and features from many other languages...

by this time, I also expect notable mutations in terms of kernel
architecture and filesystems, us likely facing the demise of both processes
and heirarchical filesystems... Linux either facing replacement, or being
internally restructured into something almost unrecognizable...

and so on...

as noted, this is mostly all just speculation here...

Looking at the past is always easy.
Prophecy proves more difficult.

 

[Bartc]

user923005 wrote:


That's why the toast crumbs keep accumulating at the bottom.

There might be a little tray that you can slide out to remove the crumbs
easily.

 

[Bartc]

In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:

<quote>
DDJ: Which languages seem to be losing ground?

PJ: C and C++ are definitely losing ground. There is a simple explanation
for this. Languages without automated garbage collection are getting out
of fashion. The chance of running into all kinds of memory problems is
gradually outweighing the performance penalty you have to pay for garbage
collection.
<end quote>

lcc-win has been distributing a GC since 2004.

I've little idea about GC or how it works (not about strategies and things
but how it knows what goes on in the program).

What happens in this code fragment:

void fn(void) {
int *p = malloc(1236);
}

when p goes out of scope? (Presumably some replacement for malloc() is
used.)

What about a linked list when it's no longer needed? How does GC know that,
do you tell it? And it knows where all the pointers in each node are. I can
think of a dozen ways to confuse a GC so it all sounds like magic to me, if
it works.