From: Timothy Miller <miller@techsource.com>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org,
linux-c-programming <linux-c-programming@vger.kernel.org>
Subject: Re: Garbage Collection and Swap
Date: Tue, 13 Jul 2004 18:10:55 -0400 [thread overview]
Message-ID: <40F45DEF.8060307@techsource.com> (raw)
In-Reply-To: <40EF3BCD.7080808@comcast.net>
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?
I get the impression that the Java VM, for instance, knows what
variables are pointers (well, references) and only considers those. It
also knows every object that has even been allocated. It scans over
every pointer it knows about (the "mark" phase), and then it scans over
every dynamically allocated memory block (the "sweep" phase) and removes
all that have no references.
There is anecdotal evidence that this approach sometimes can improve
performance over "manual" freeing because freeing can be done in bulk.
Java GC works very well, and it's a huge improvement over the "manual"
method, because it almost completely eliminates memory leaks (if you
really want a memory leak, you can find a way to make it happen).
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
fact that you can do MATH on pointers in C makes reliable GC nearly
impossible, although any reasonable attempt would certainly be better
than your assumption that something would "go scanning through memory
looking for things that look like pointers." That would be horribly
stupid. Better would be to have the compiler emit code that registers
pointers with something that keeps track of them, but that's still a
huge can of worms when you consider someone malloc'ing N bytes, storing
a (void *), and then later assigning that value to a struct pointer.
No, I don't think GC in C is feasible.
next prev parent reply other threads:[~2004-07-13 22:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-10 0:43 Garbage Collection and Swap John Richard Moser
2004-07-10 2:32 ` William Lee Irwin III
2004-07-10 3:10 ` John Richard Moser
2004-07-11 0:57 ` Rik van Riel
2004-07-11 1:06 ` Rik van Riel
2004-07-11 2:10 ` John Richard Moser
2004-07-13 22:10 ` Timothy Miller [this message]
2004-07-13 23:53 ` John Richard Moser
2004-07-20 16:47 ` array size 1 ? Anshuman S. Rawat
2004-07-21 2:49 ` Luiz Fernando N. Capitulino
2004-07-21 3:48 ` Glynn Clements
2004-08-08 5:37 ` Sascha Retzki
2004-07-14 10:20 ` Garbage Collection and Swap IVAN DE JESUS DERAS TABORA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40F45DEF.8060307@techsource.com \
--to=miller@techsource.com \
--cc=linux-c-programming@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).