Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Garbage collection

Reply
Thread Tools

Garbage collection

 
 
Richard Tobin
Guest
Posts: n/a
 
      04-25-2008
In article <futh8h$cp7$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> 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.


>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
 
Reply With Quote
 
 
 
 
Paul Hsieh
Guest
Posts: n/a
 
      04-25-2008
On Apr 25, 5:16 am, jacob navia <(E-Mail Removed)> wrote:
> 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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      04-25-2008
jacob navia <(E-Mail Removed)> writes:
> 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, 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_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      04-25-2008
William Ahern wrote, On 25/04/08 20:33:
> user923005 <(E-Mail Removed)> wrote:
>> On Apr 25, 5:16?am, jacob navia <(E-Mail Removed)> wrote:
>>> 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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-25-2008
Paul Hsieh wrote:
> On Apr 25, 5:16 am, jacob navia <(E-Mail Removed)> wrote:
>> 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.
>


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.


> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-25-2008
Keith Thompson wrote:
>
> 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!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      04-25-2008

"Yunzhong" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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...



 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      04-25-2008
On Apr 25, 3:34*pm, "cr88192" <(E-Mail Removed)> wrote:
> "Yunzhong" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> >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...


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

 
Reply With Quote
 
Bartc
Guest
Posts: n/a
 
      04-25-2008

"Eric Sosman" <(E-Mail Removed)> wrote in message
news:1209149152.181452@news1nwk...
> 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


 
Reply With Quote
 
Bartc
Guest
Posts: n/a
 
      04-25-2008

"jacob navia" <(E-Mail Removed)> wrote in message
news:fusi33$e0n$(E-Mail Removed)...
>
> 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.

--
Bart


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Collection problems (create Collection object, add data to collection, bind collection to datagrid) Řyvind Isaksen ASP .Net 1 05-18-2007 09:24 AM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM
Garbage Collection kamran MCSD 1 04-04-2005 10:04 PM
Garbage Collection and Manage Code? Laser Lu ASP .Net 5 01-27-2004 03:48 AM
Debbugging help! (.NET 1.1 Framework Garbage Collection Problems) Cheung, Jeffrey Jing-Yen ASP .Net 3 07-10-2003 07:29 PM



Advertisments