Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > When to use a garbage collector?

Reply
Thread Tools

When to use a garbage collector?

 
 
Carlo Milanesi
Guest
Posts: n/a
 
      06-10-2008
Hello,
traditionally, in C++, dynamically allocated memory has been
managed explicitly by calling "delete" in the application code.

Now, in addition to the standard library strings, containers, and
auto_ptrs, gurus suggest that may be better to use a reference-counted
smart pointer, or a garbage-collector.

But in which cases it is better to use one technique and in which cases
another? IOW, which is the design criterion?

And if, after having completed a working system, a technique would
result more performing than another, or better for other reasons, is it
advisable to change the memory management strategy of that working system?

--
Carlo Milanesi
http://digilander.libero.it/carlmila
 
Reply With Quote
 
 
 
 
Krice
Guest
Posts: n/a
 
      06-10-2008
On 10 kesä, 18:30, Carlo Milanesi <(E-Mail Removed)>
wrote:
> But in which cases it is better to use one technique and in which cases
> another?


It's probably a question that has no answer. But I like the
old school delete, because it's transparent, you know exactly
what it's doing and when.
 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      06-10-2008
In article <484e9dfd$0$17941$(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...

[ ... ]

> Now, in addition to the standard library strings, containers, and
> auto_ptrs, gurus suggest that may be better to use a reference-counted
> smart pointer, or a garbage-collector.


_Some_ gurus -- there are others (who I think qualify as gurus) who are
opposed to the use of garbage collection to varying degrees, or at least
are of the view that its use should be restricted to specific
situations.

> But in which cases it is better to use one technique and in which cases
> another? IOW, which is the design criterion?


The cost of garbage collection varies based on the type of collector
used. Nearly every garbage collector has a "mark" phase, in which
"live" objects (i.e. those that are still accessible) are marked as
being in use. The cost of this phase is normally about linear on the
number of objects currently accessible to the program.

After that, different garbage collectors work in a number of different
ways. A copying collector copies all those live objects into a
contiguous space in memory, leaving another contiguous free space. This
makes allocations extremely cheap, and the cost of the collection as a
whole is also linear on the number of objects that are accessible.

Other collectors leave the "live" objects where they are, and create
free blocks of all the contiguous chunks of memory in the heap not
currently occupied by live objects. In this case, the cost of the
collection part tends to relate most closely to the number of contiguous
chunks of free memory in the heap.

On the other side, life isn't simple either. Manual memory management
tends to have costs associated most closely with the number of
allocations and frees used. This cost can be mitigated (drastically) in
certain cases, such as allocating a large number of objects of identical
size, or releasing a large number of objects all at the same, if the
allocator is written to allow them to be released together rather than
individually.

That only begins to tell the real story though: much of the cost of
manual allocation/deletion arises when objects are copied. A garbage
collector can (and does) keep track of different pointers that refer to
an object, and only deletes the object when all pointers that give
access to the object are gone. This makes it easy to keep a single
object, and create new pointers/references to that object whenever
needed.

With manual memory management, it's far more common to duplicate the
entire object, so each time the object is used, there's a separate
instance of the object to look at, and each instance has exactly one
owner that's responsible for deleting the object when it's no longer
needed. Allocating space to hold extra copies of the object, and copying
the relevant data into each copy, can take a considerable amount of
time. With a GC in place, you can usually avoid this copying by just
passing around pointers and everything shares access to that one object.
OTOH, when/if you need to copy the object anyway (e.g. if one copy will
be modified to become different from the other), this does little good.

As such, a tremendous amount depends upon things like: 1) what you're
allocating dynamically, 2) how you're using the dynamically allocated
objects, and 3) the degree to which objects you'd copy with manual
memory management can be shared in the presence of GC. All of these (and
more) depend on the application and design, not just the memory
management itself.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-10-2008
Jerry Coffin <(E-Mail Removed)> writes:
>Allocating space to hold extra copies of the object, and copying
>the relevant data into each copy, can take a considerable amount of
>time. With a GC in place, you can usually avoid this copying by just
>passing around pointers and everything shares access to that one object.


»There were two versions of it, one in Lisp and one in
C++. The display subsystem of the Lisp version was faster.
There were various reasons, but an important one was GC:
the C++ code copied a lot of buffers because they got
passed around in fairly complex ways, so it could be quite
difficult to know when one could be deallocated. To avoid
that problem, the C++ programmers just copied. The Lisp
was GCed, so the Lisp programmers never had to worry about
it; they just passed the buffers around, which reduced
both memory use and CPU cycles spent copying.«

<XNOkd.7720$(E-Mail Removed)>

»A lot of us thought in the 1990s that the big battle would
be between procedural and object oriented programming, and
we thought that object oriented programming would provide
a big boost in programmer productivity. I thought that,
too. Some people still think that. It turns out we were
wrong. Object oriented programming is handy dandy, but
it's not really the productivity booster that was
promised. The real significant productivity advance we've
had in programming has been from languages which manage
memory for you automatically.«

http://www.joelonsoftware.com/articles/APIWar.html

»[A]llocation in modern JVMs is far faster than the best
performing malloc implementations. The common code path
for new Object() in HotSpot 1.4.2 and later is
approximately 10 machine instructions (data provided by
Sun; see Resources), whereas the best performing malloc
implementations in C require on average between 60 and 100
instructions per call (Detlefs, et. al.; see Resources).
And allocation performance is not a trivial component of
overall performance -- benchmarks show that many
real-world C and C++ programs, such as Perl and
Ghostscript, spend 20 to 30 percent of their total
execution time in malloc and free -- far more than the
allocation and garbage collection overhead of a healthy
Java application (Zorn; see Resources).«

http://www-128.ibm.com/developerwork...vaUrbanLegends

»Perhaps the most important realisation I had while developing
this critique is that high level languages are more important
to programming than object-orientation. That is, languages
which have the attribute that they remove the burden of
bookkeeping from the programmer to enhance maintainability and
flexibility are more significant than languages which just
add object-oriented features. While C++ adds object-orientation
to C, it fails in the more important attribute of being high
level. This greatly diminishes any benefits of the
object-oriented paradigm.«

http://burks.brighton.ac.uk/burks/pc...t/index005.htm


 
Reply With Quote
 
AnonMail2005@gmail.com
Guest
Posts: n/a
 
      06-10-2008
On Jun 10, 11:30*am, Carlo Milanesi <(E-Mail Removed)>
wrote:
> Hello,
> * * *traditionally, in C++, dynamically allocated memory has been
> managed explicitly by calling "delete" in the application code.
>
> Now, in addition to the standard library strings, containers, and
> auto_ptrs, gurus suggest that may be better to use a reference-counted
> smart pointer, or a garbage-collector.
>
> But in which cases it is better to use one technique and in which cases
> another? IOW, which is the design criterion?
>
> And if, after having completed a working system, a technique would
> result more performing than another, or better for other reasons, is it
> advisable to change the memory management strategy of that working system?


I almost always use smart pointers for objects. In any moderately
sized
system, the complexity of figuring out when to delete something is
just
not worth it. With smart pointers, you never have to delete.

Of course, memory managed *within* a class can be handled with raw
pointers.

So I don't see a real choie between using deletes and using smart
pointers
unless there is a special circumstance or platform.

We have yet to move or consider other forms of garbage collectors such
as that used in Java. Call me old fashioned .
 
Reply With Quote
 
acehreli@gmail.com
Guest
Posts: n/a
 
      06-10-2008
On Jun 10, 9:42 am, Krice <(E-Mail Removed)> wrote:
> On 10 kesä, 18:30, Carlo Milanesi <(E-Mail Removed)>
> wrote:
>
> > But in which cases it is better to use one technique and in which cases
> > another?

>
> It's probably a question that has no answer. But I like the
> old school delete, because it's transparent, you know exactly
> what it's doing and when.


I don't think so. Can you tell whether the delete here will be called:

void foo()
{
A * a = new A(/* ... */);
/* code that may throw today or some time in the future possibly
after some code change */
delete a;
}

To the OP: never deallocate resources explicitly in code. That would
not be "traditional," rather "developmental." I used to do that
when I didn't know better. :/

Ali
 
Reply With Quote
 
acehreli@gmail.com
Guest
Posts: n/a
 
      06-10-2008
On Jun 10, 12:03 pm, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> On Jun 10, 11:30 am, Carlo Milanesi <(E-Mail Removed)>
> wrote:


> I almost always use smart pointers for objects. In any moderately
> sized
> system, the complexity of figuring out when to delete something is
> just
> not worth it.


The problem is, that complex code hoping to figure out when to
'delete' an object may never be executed. The non-throwing lines of
code of today can suddenly start possibly throwing in the future by
code changes, and the explicit delete statement may never be executed.

> Of course, memory managed *within* a class can be handled with raw
> pointers.


Unfortunately that statement must be qualified further: you are
talking about classes that manage a single object, right? Because the
following class fits your description, but is not exception-safe and
cannot manage the memory it hopes to manage:

class HopefulManager
{
One * one_;
Two * two_;

public:

HopefulManager()
:
one_(new One()),
two_(new Two()) // <- 1, <- 2
{
// some other code that may throw <- 3
}

~HopefulManager()
{
delete two_;
delete one_;
}
};

The three places that may cause resource leaks are:

1) new may throw, one_'s object is leaked

2) Two() may throw, one_'s object is leaked

3) Any line is the constructor may throw, one_'s and two_'s objects
are leaked

> So I don't see a real choie between using deletes and using smart
> pointers
> unless there is a special circumstance or platform.


What I said above is regardless of special circumstances or platforms.
Pure C++...

Ali
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-10-2008
In article <(E-Mail Removed)-berlin.de>,
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de says...
> Jerry Coffin <(E-Mail Removed)> writes:
> >Allocating space to hold extra copies of the object, and copying
> >the relevant data into each copy, can take a considerable amount of
> >time. With a GC in place, you can usually avoid this copying by just
> >passing around pointers and everything shares access to that one object.

>
> »There were two versions of it, one in Lisp and one in
> C++. The display subsystem of the Lisp version was faster.
> There were various reasons, but an important one was GC:
> the C++ code copied a lot of buffers because they got
> passed around in fairly complex ways, so it could be quite
> difficult to know when one could be deallocated. To avoid
> that problem, the C++ programmers just copied. The Lisp
> was GCed, so the Lisp programmers never had to worry about
> it; they just passed the buffers around, which reduced
> both memory use and CPU cycles spent copying.«
>
> <XNOkd.7720$(E-Mail Removed)>


Intentionally or otherwise, I suspect your post is likely to generate
fare more heat than light. Most of it is unsupported assertions, and
none of it is from anybody who appears to deserve the title of "guru",
at least with respect to C++ (and IMO, probably not in any other respect
either).

The first quote appears to be purely apocryphal -- an unsupported
statement from somebody posting under a pseudonym, about software of
unknown origin written by people of unknown skills.

Joel Spolsky spends a lot of time writing about software, but his
credentials seem questionable at best. In particular, I've seen nothing
to give a really strong indication that he's much of a programmer
(himself) at all.

IBM, of course, has a great deal of collective knowledge about
programming -- but the bit you quote is written with the specific intent
of promoting Java. It's been discussed here before, and at very best
it's misleading when applied to more than the very specific domain about
which it's written.

Finally we get yet another reference to Ian Joyner's "Critique of C++."
IMO, there should be something similar to Godwin's law relating to
anybody who quotes (any part of) this. First of all, it has nothing to
do with the C++ of today, or anytime in the last decade or more. As of
the first edition, some (a small fraction) was reasonably accurate about
the C++ of the time -- but the updates in his second and third editions
were insufficient to keep the relevant to the C++ of their times, and
the third edition still predates the original C++ standard by a couple
of years. With respect to the C++ of today, it varies from irrelevant to
misleading to downright false. Second, a great deal of it was misleading
when it was originally written. Third, nearly all the rest of it was
downright false when written.

When you get down to it, despite being umpteen pages long, the
criticisms in this paper that have at least some degree of validity with
respect to current C++ can be summarized as:

1) member functions should be virtual by default.
2) C++ should have Concepts [JVC: C++ 0x will].
3) Unified syntax for "." and "->" would be nice.
4) "static" is overloaded in too many (confusing) ways.
5) Modules would be better than headers.
6) Support for DbC would have some good points.

When you get down to it, however, it would be much easier to summarize
his critique in a single sentence: "C++ isn't Eiffel." Many of his
individual arguments aren't really supported at all -- they're simply
statements that C++ must be wrong because it's different from Eiffel.

Don't get me wrong: my previous statement that GC is favored for some
situations under some circumstances still stands -- but IMO, none of
these quotes provides any real enlightenment. Quite the contrary, the
quote from IBM means _almost_ nothing, and the other three (between
them) mean far less still.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Fran
Guest
Posts: n/a
 
      06-11-2008
On Jun 10, 5:37 pm, (E-Mail Removed) wrote:

> The problem is, that complex code hoping to figure out when to
> 'delete' an object may never be executed. The non-throwing lines of
> code of today can suddenly start possibly throwing in the future by
> code changes, and the explicit delete statement may never be executed.


Is there any chance that C++0x will give us mandatory checking of
throw() clauses in function definitions? That would enable the
compiler to warn about leaks when exceptions might happen between
calls to new and delete.
--
franl
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-11-2008
On Jun 11, 12:54 am, Jerry Coffin <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)-berlin.de>,
> (E-Mail Removed)-berlin.de says...
> > Jerry Coffin <(E-Mail Removed)> writes:
> > >Allocating space to hold extra copies of the object, and
> > >copying the relevant data into each copy, can take a
> > >considerable amount of time. With a GC in place, you can
> > >usually avoid this copying by just passing around pointers
> > >and everything shares access to that one object.


> > »There were two versions of it, one in Lisp and one in
> > C++. The display subsystem of the Lisp version was faster.
> > There were various reasons, but an important one was GC:
> > the C++ code copied a lot of buffers because they got
> > passed around in fairly complex ways, so it could be quite
> > difficult to know when one could be deallocated. To avoid
> > that problem, the C++ programmers just copied. The Lisp
> > was GCed, so the Lisp programmers never had to worry about
> > it; they just passed the buffers around, which reduced
> > both memory use and CPU cycles spent copying.«


> > <XNOkd.7720$(E-Mail Removed)>


> Intentionally or otherwise, I suspect your post is likely to
> generate fare more heat than light. Most of it is unsupported
> assertions, and none of it is from anybody who appears to
> deserve the title of "guru", at least with respect to C++ (and
> IMO, probably not in any other respect either).


You noticed that too.

> The first quote appears to be purely apocryphal -- an
> unsupported statement from somebody posting under a pseudonym,
> about software of unknown origin written by people of unknown
> skills.


The first quote is probably the one which does correspond most
to practical reality; I seem to recall a similar statement being
made by Walter Bright (who certainly does qualify as a C++
guru). But of course, it doesn't have to be that way.

> Joel Spolsky spends a lot of time writing about software, but
> his credentials seem questionable at best. In particular, I've
> seen nothing to give a really strong indication that he's much
> of a programmer (himself) at all.


Another case of "those who can, do; those who can't teach (or
write articles)".

> IBM, of course, has a great deal of collective knowledge about
> programming -- but the bit you quote is written with the
> specific intent of promoting Java. It's been discussed here
> before, and at very best it's misleading when applied to more
> than the very specific domain about which it's written.


> Finally we get yet another reference to Ian Joyner's "Critique
> of C++." IMO, there should be something similar to Godwin's
> law relating to anybody who quotes (any part of) this. First
> of all, it has nothing to do with the C++ of today, or anytime
> in the last decade or more. As of the first edition, some (a
> small fraction) was reasonably accurate about the C++ of the
> time -- but the updates in his second and third editions were
> insufficient to keep the relevant to the C++ of their times,
> and the third edition still predates the original C++ standard
> by a couple of years. With respect to the C++ of today, it
> varies from irrelevant to misleading to downright false.
> Second, a great deal of it was misleading when it was
> originally written. Third, nearly all the rest of it was
> downright false when written.


> When you get down to it, despite being umpteen pages long, the
> criticisms in this paper that have at least some degree of
> validity with respect to current C++ can be summarized as:


> 1) member functions should be virtual by default.


Which is just wrong, at least from a software engineering point
of view.

> 2) C++ should have Concepts [JVC: C++ 0x will].
> 3) Unified syntax for "." and "->" would be nice.


I don't think I agree with this one, either.

> 4) "static" is overloaded in too many (confusing) ways.


The price we pay for C compatibility.

> 5) Modules would be better than headers.


I don't think anyone could disagree with that one. Of course,
just about everyone has a different definition of what they mean
by "modules".

> 6) Support for DbC would have some good points.


Interestingly, I think that C++ today has the best support of
any language, although it's not automatic, and many programmers
fail to use it.

> When you get down to it, however, it would be much easier to
> summarize his critique in a single sentence: "C++ isn't
> Eiffel." Many of his individual arguments aren't really
> supported at all -- they're simply statements that C++ must be
> wrong because it's different from Eiffel.


> Don't get me wrong: my previous statement that GC is favored
> for some situations under some circumstances still stands --
> but IMO, none of these quotes provides any real enlightenment.
> Quite the contrary, the quote from IBM means _almost_ nothing,
> and the other three (between them) mean far less still.


I don't think that there is complete consensus among the gurus
as to when garbage collection would be appropriate. I would be
very suspicious, however, of anyone who claimed that it is
always appropriate, or never appropriate. That it's not
available in the standard toolkit is a definite flaw in the
language, but requiring it to be used in every case would
probably be even worse (but I don't think anyone has ever
proposted that).

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
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
Re: Do you use a garbage collector (java vs c++ difference in "new") Arne Vajhøj Java 12 04-13-2008 12:13 AM
Re: Do you use a garbage collector (java vs c++ difference in "new") Ian Collins Java 0 04-11-2008 02:41 AM
When to use Boehm-Demers-Weiser Garbage Collector? PengYu.UT@gmail.com C++ 0 03-30-2006 04:37 AM
Just Curious, What Kind Of Garbage Collector Does Sun's JVM Use? res7cxbi@verizon.net Java 2 01-06-2006 11:29 AM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM



Advertisments