-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Timothy Miller wrote:
|
|
| John Richard Moser wrote:
|
|>
|> THE GARBAGE COLLECTOR WANDERS AROUND IN THE ENTIRE HEAP, AND IN SOME
|> CASES IN OTHER PARTS OF RAM, LOOKING FOR WHAT LOOKS LIKE POINTERS TO
|> YOUR ALLOCATED DATA.
|>
|
| Whose GC does this?
|

http://www.iecc.com/gclist/GC-faq.html


## C-compatible garbage collectors know where pointers may generally be
## found (e.g., "bss", "data", and stack), and maintain heap data
## structures that allow them to quickly determine what bit patterns
## might be pointers. Pointers, of course, look like pointers, so this
## heuristic traces out all memory reachable through pointers. What
## isn't reached, is reclaimed.

This just sticks out in my face
| I get the impression that the Java VM, for instance, knows what
[...]

blah blah java blah blah

Yeah Java was built around garbage collection, let's not talk about
this; I was talking about C.

|
| There is anecdotal evidence that this approach sometimes can improve
| performance over "manual" freeing because freeing can be done in bulk.
|

Dude.

if (check_for_tons_of_crap_that_says_I_am_not_used(p))
free(p);

Yeah.  It's a pain in the ass to check every time you turn around for
conditions that indicate that p is unused.  In some cases, it's a best
effort; you can't always tell.  I can believe that GC would be more
passive; hell, if it's not, just slow the GC down a bit.  Garbage
collection doesn't make sure there's no allocated ram that's not in use;
it only frees things it can determine as such.

| Java GC works very well, and it's a huge improvement over the "manual"

[...]

blah blah java blah blah

Everything is an improvement over manual mm.

|
| Now, if you're talking about trying to apply GC to C code, it's an
| entirely different matter.  C wasn't designed with GC in mind.  The very

[...huge paragraph that makes sense...]

Yeah my thoughts exactly.

|
| No, I don't think GC in C is feasible.

See above.

|

Incidently, I've compiled a list of pros/cons from legacy/refct/mm.

I'm going to point something out here though, about comparing these.

When you compare manual mm and reference counting, you're in the same
field:  Both of these set up deterministic points in program flow where
allocated blocks will be freed if it is determined that they are no
longer in use.  Both of these occur immediately when a specific body of
code is finished with a block of memory.

With garbage collection, it's different.  The garbage collector finds
out on its own at some undefined point after the block is no longer
needed that it can free it, and does so.  The GC is in no way obligated
to free the block as soon as it is no longer in use; it only does this
when it discovers this.  As such, a GC is not the same class of
operation as the other two.  You can show me a GC that imposes less
overhead than the other two methods; and I can retune that same GC to
use 99% of your CPU.

That being said, don't argue about the overhead of a GC, because it's
completely managable.

Attached is my list of pros/cons of each system.  It's just some scrap
for data I'm collecting, not presentation material.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA9HX5hDd4aOud5P8RAjyjAJ9bOxGUoRzGg66dgLHSEC7z5yUScgCfdc6+
cPaxYGWDN4Tx5IFA3bJgFIA=
=n2yk
-----END PGP SIGNATURE-----