Garbage collection

**cr88192** · Jun 27 '08, 07:32 PM

Re: Garbage collection

"jacob navia" <jacob@nospam.c omwrote in message
news:fusi33$e0n $1@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.
>

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

>
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

**Yunzhong** · Jun 27 '08, 07:32 PM

Re: Garbage collection

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** · Jun 27 '08, 07:32 PM

Re: Garbage collection

Yunzhong wrote:

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

403 Forbidden

http://www.cs.virginia.edu/~lcc-win32

**user923005** · Jun 27 '08, 07:32 PM

Re: Garbage collection

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.

**Gordon Burditt** · Jun 27 '08, 07:32 PM

Re: Garbage collection

>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
implementation in particular, as storing pointers in files is
relatively unusual. But a standards-compliant GC has to deal with
it.

**Eric Sosman** · Jun 27 '08, 07:32 PM

Re: Garbage collection

user923005 wrote:

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?

Google has lots of hits for "Paul Jansen," starting with
a firm that makes piano benches. Adding "Dobbs" to the query
leads us to a Paul Jansen who's the managing director of TIOBE
Software. Never heard of them, but they have something called
the "TIOBE Programming Community Index" that apparently tries
to measure the "popularity of programming languages," but does
so by estimating "their web presence." This they do by running
searches of the form "X programming" for various language names,
and counting the hits.

Sounds like phrenology, doesn't it? Or perhaps astrology?
Maybe we need a new word for this sort of research, something
like "gullibolog y," or better yet "apology."

Interesting factoid: According to Jansen, COBOL is not
among the top ten most popular languages, having been edged
out by Python -- within the last five years! The Amazing
Grace had more staying power than people thought ...

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

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

--
Eric.Sosman@sun .com

**Richard** · Jun 27 '08, 07:32 PM

Re: Garbage collection

Eric Sosman <Eric.Sosman@su n.comwrites:

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

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

**santosh** · Jun 27 '08, 07:32 PM

Re: Garbage collection

Gordon Burditt wrote:

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

**William Ahern** · Jun 27 '08, 07:32 PM

Re: Garbage collection

user923005 <dcorbit@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.

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
well-defined specifications (XML, HTTP), and other "optimizing " parts of
applications in more higher-level languages, not to mention virtual
machines, etc. C is a simple language, and it can express these solutions
quite readily.

Because of the way software systems are constructed (especially "edge"
systems, like web applications), and because of the growth of the IT sector
(particularly in number of programmers), it's inevitable that C will become
_relatively_ diminished. By itself, of course, this means very little for C.
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.

Before Java and C# there was Visual Basic and Delphi. There's still Visual
Basic. There are untold numbers of people programming in PHP. I remember
when Cold Fusion came out. Many corporations jumped on it because it
promised managers the ability to repurpose "functional " personnel for doing
"technical" work; i.e. turn your average Joe into a "programmer ". There's
nothing wrong w/ that, but when it happens it doesn't mean C is becoming
less popular in the sense that its role is being overcome by other
languages. And there's no reason to think that C is "retreating " to the
hidden world of toaster software anymore than it always has; which is to
say: it's not.

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.

**Chris Thomasson** · Jun 27 '08, 07:32 PM

Re: Garbage collection

"jacob navia" <jacob@nospam.c omwrote in message
news:fusi33$e0n $1@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** · Jun 27 '08, 07:32 PM

Re: Garbage collection

>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** · Jun 27 '08, 07:32 PM

Re: Garbage collection

santosh <santosh.k83@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) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

**Keith Thompson** · Jun 27 '08, 07:32 PM

Re: Garbage collection

"Chris Thomasson" <cristom@comcas t.netwrites:

"jacob navia" <jacob@nospam.c omwrote in message
news:fusi33$e0n $1@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) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

**jacob navia** · Jun 27 '08, 07:32 PM

Re: Garbage collection

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

403 Forbidden

http://www.cs.virginia.edu/~lcc-win32

Garbage collection

Garbage collection

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment