Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Garbage collection

 
 
jacob navia
Guest
Posts: n/a
 
      04-25-2008

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
 
Reply With Quote
 
 
 
 
cr88192
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.
>
> 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



 
Reply With Quote
 
 
 
 
Yunzhong
Guest
Posts: n/a
 
      04-25-2008
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.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-25-2008
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
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
user923005
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:


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.
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      04-25-2008

Eric Sosman <(E-Mail Removed)> writes:

>> 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.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-25-2008
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.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-25-2008
santosh <(E-Mail Removed)> writes:
> 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
>> 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.


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_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
 
Keith Thompson
Guest
Posts: n/a
 
      04-25-2008
"Chris Thomasson" <(E-Mail Removed)> writes:
> "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.
>>
>> 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_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
 
jacob navia
Guest
Posts: n/a
 
      04-25-2008
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
 
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