linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).