·····@msn.com (muzo) writes:
>···@math.keio.ac.jp (MAEDA Atusi) wrote:
>>You must be joking. Aside from higher programming cost (for worrying
>>about memory leak and dangling pointers), malloc/free (or new/delete)
>>is generally slower than cons/gc because cost of free is proportional
>>to the amount of objects died during computation while gc cost isn't.
>
>just a sec. Are you saying that the number of free call necessary in a GC
>system is different than the number of free calls in a malloc/free program
>which allocates the same number of objects ? If yes, I'd like to see a
>reference or discussion on this.
>
>If you are not saying that (which I don't think you can), than a "perfectly
>implemented" malloc/free program has a lower bound in terms of memory
>management cost because the "programmer" (remember that person who wrote the
>perfect program ?) knows exactly when the memory is not needed anymore and
>doesn't incur any costs for finding out which objects are to be collected.
If programmers are so good at this, then why are tools like Purify
necessary?
-- Kevin Gallagher
I've been a C programmer for over 500 years.
And I would NEVER leave a trail of allocated memory behind.
Honest.
Seriously.
No kidding.
Sure.
That's the ticket..
That's right :)
-= Bob =-
--
================================================================
= Bob Jamison 713-244-5769 = ········@gothamcity.jsc.nasa.gov =
================================================================
On Fri, 20 Oct 1995 15:56:47 GMT, ·······@world.std.com (MORE Systems) said:
> Which is better? Well, on the one hand, malloc/free does require
> more overhead per allocation when the cost of freeing memory is
> factored in. However, garbage collection has to periodically scan
> through all of dynamic memory to clean up the garbage, which on a
> heavily loaded virtual-memory environment can thrash the disk like
> you wouldn't believe. Each has their merits, and the jury is still
> out, as it were.
Assuming you're referring to refcounting, there is also the cost of
storing and maintaining the reference counts. That's a real cost that
may also adversely effect virtual memory usage patterns.
Anyway, many modern GCs are "generational," meaning that they don't
necessarily have to traverse every live object at every GC. This and
other advances in GC techniques over the traditional stop-and-copy
collector are prerequisites for understanding the tradeoffs. I
suggest interested parties read Henry Baker's papers in
ftp://ftp.netcom.com/pub/hb/hbaker and Paul Wilson's collection in
ftp://ftp.cs.utexas.edu/pub/garbage.
> allocation scheme that anyone might come up with. Remember, these
> languages only expect that somehow the memory will be managed: It's
> up to the interpereter or compiler to figure out exactly how to do
Again assuming refcounting, most of the implementations I know about
aren't quite equal to their GC counterparts. For example, circular
references in a refcounted environment will usually result in a
storage leak unless you explicitly break them, whereas a garbage
collector would handle the situation properly without programmer
intervention. When writing a program that uses a lot of circular
references, it's nice to know that they'll be freed. Sometimes you
also want to know *when* an object will be freed, and whether you can
associate a finalization action with it. All these things may
influence the choice of memory management strategies for a language.
-- Robert
--
MindSpring: use us and nobody gets hurt.
From: MORE Systems
Subject: Re: Garbage collection cost (was Re: Parenthesized syntax challenge)
Date:
Message-ID: <MORESYS.95Oct20115647@world.std.com>
I think anyone who seriously thinks that human programmers can be
better than computers at managing dynamic memory should have their
head examined...
"Nah, I don't use that garbage collection stuff, I can do it better
myself... Huh? DAMN! Another segmentation fault! I've been trying to
track that down for months! Oh well. As I was saying, garbage
collection wastes too much time. Now if you can excuse me, I have
a lot of work to do. My project is already late..."
The REAL question is whether or not 'garbage collection', which
usually involves periodically sweeping through dynamically-allocated
memory to find unreferencable data structures, is better than the
malloc/free paradigm, which with slight alterations can be built right
into the language, requiring no programmer participation and
introducing no possibility of human error.
Which is better? Well, on the one hand, malloc/free does require more
overhead per allocation when the cost of freeing memory is factored
in. However, garbage collection has to periodically scan through all
of dynamic memory to clean up the garbage, which on a heavily loaded
virtual-memory environment can thrash the disk like you wouldn't
believe. Each has their merits, and the jury is still out, as it were.
Until a clear winner emerges, however, it would be perfectly possible
to implement a version of Dylan, Lisp, or Java which uses either
method, a hybrid of both, or any other kind of memory allocation
scheme that anyone might come up with. Remember, these languages only
expect that somehow the memory will be managed: It's up to the
interpereter or compiler to figure out exactly how to do it.
-Eugene (·······@world.std.com)
·······@world.std.com (MORE Systems) writes:
>Which is better? Well, on the one hand, malloc/free does require more
>overhead per allocation when the cost of freeing memory is factored
>in. However, garbage collection has to periodically scan through all
>of dynamic memory to clean up the garbage, which on a heavily loaded
>virtual-memory environment can thrash the disk like you wouldn't
>believe. Each has their merits, and the jury is still out, as it were.
>Until a clear winner emerges, however, it would be perfectly possible
>to implement a version of Dylan, Lisp, or Java which uses either
>method, a hybrid of both, or any other kind of memory allocation
>scheme that anyone might come up with. Remember, these languages only
>expect that somehow the memory will be managed: It's up to the
>interpereter or compiler to figure out exactly how to do it.
Ummm. Java is allocating objects. As references to those objects are made
and unmade it knows when an object becomes unreferenced. At which point
it can just be added to the fodder list for the garbage collector. If
there's a another list of referenced objects all the gc has to do is run
the two lists...
Mik