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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Chris Thomasson]

"jacob navia" <ja***@nospam.c omwrote in message
news:fu******** **@aioe.org...

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

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.

[Gordon Burditt]

>I don't consider this to be a fatal flaw for GC in general or this

>implementati on 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

Yes, we can. GC doesn't have to do anything different from the perspective
of a C program, although for 'real' GC it has to be able to collect some
garbage.

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

No, using GC is allowed under 'as if' rules provided it doesn't make
any mistakes. Similar issues apply to swapping and paging - also not
specifically mentioned by the standard. There are
no rules against things like long pauses, poor performance, or similar
things. However, if GC mistakenly releases memory in use, then
reallocates it or otherwise lets it get scribbled on, it's in violation
of the 'as if' rule.

[Keith Thompson]

santosh <sa*********@gm ail.comwrites:

Gordon Burditt wrote:

>jacob navia wrote (and Gordon Burditt rudely snipped the attribution):

>>>lcc-win has been distributing a GC since 2004.

It really helps.

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

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 (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Chris Thomasson" <cr*****@comcas t.netwrites:

"jacob navia" <ja***@nospam.c omwrote in message
news:fu******** **@aioe.org...

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

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

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

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
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Tobin]

In article <fu**********@a ioe.org>, jacob navia <ja***@nospam.o rgwrote:

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

>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
--
:wq

[Keith Thompson]

jacob navia <ja***@nospam.c omwrites:

Keith Thompson wrote:

>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
representati on 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

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.

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

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

user923005 <dc*****@connx. comwrote:

>On Apr 25, 5:16?am, jacob navia <ja...@nospam.c omwrote:

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

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

<snip>

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.

<snip>

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

[Eric Sosman]

jacob navia wrote:

Keith Thompson wrote:

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

Um, er, isn't that what he said in the part you snipped?
It went like this (emphasis mine):

:[...] 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.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^

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

The people who "care about memory management" don't need GC:
They manage their memory themselves *because* they care about it.
GC is for the people who choose not to manage their memory; just
dropping memory on the floor and letting GC sweep it up is prima-
facie evidence that the programmer does *not* "care about memory
management" and chooses to leave it to someone else.

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

GC has practical advantages for some programming languages;
nobody disputes that. I cannot imagine LISP without it, nor
SNOBOL, nor Java, and others I've never used. But the fact that
languages X,Y,Z benefit from garbage collection does not imply
that all languages would, nor even that any particular other
language would. The same could be said for pretty much any
other language feature you care to name: FORTRAN benefits from
built-in complex numbers, but does that mean awk needs them?
Perl benefits from built-in regular expression machinery; does
that mean assembly language should have it, too?

In my opinion, it is not helpful to C to try to lard it up
with every cute feature of every programming environment every
enthusiast ever sighed over.

--
Er*********@sun .com

[Bartc]

"Eric Sosman" <Er*********@su n.comwrote in message
news:1209149152 .181452@news1nw k...

user923005 wrote:

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

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.

--
Bart