From: John Richard Moser <nigelenki@comcast.net>
To: linux-kernel@vger.kernel.org,
linux-c-programming <linux-c-programming@vger.kernel.org>
Subject: Garbage Collection and Swap
Date: Fri, 09 Jul 2004 20:43:57 -0400 [thread overview]
Message-ID: <40EF3BCD.7080808@comcast.net> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been researching garbage collection.
Let me first get it out in the open that I *despise* the concept of
garbage collection. I worried when I first heard of a magical automatic
free()/delete[] that it would do one or more of two things:
~ - Create excessive overhead
~ - Free up ram I'm still using
I've learned that the first may or may not be true. This means that
they've won on some accounts with that one.
The second may or may not occur as well. It worries me that it may in
certain cases, due to the way GC works. Most garbage collectors will
look in the heap, maybe the stack, maybe other places, for what looks
like pointers to allocated ram. If they don't find any, they free the ram.
So, the first extremely obvious thing you'll notice is that GC may at
times miss things, especially if you use the XOR linked list trick or
use your own makeshift swap file (write pointers to disk, read back in).
After a while, a big one hit me.
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.
Read that. It's in all caps, so you should read it. It has meaning.
How about, everything is using Bohem GC. Bohem wanders around in the
heap concurrently. So all of your applications are wandering around
through their vm space everywhere, continuously.
You get low on ram. Let's say an app is using 500M of ram (Mozilla).
What's going to happen? Obvious. It's going to yank shit out of swap.
If we all linked against a GC, what kinds of swap hell do you think we'd
encounter?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA7zvMhDd4aOud5P8RAh8zAJ9zTAH2D+aJOpK60Gz2FiWfKE/iYQCfShG1
GuXdbh0ZRJuwCX2fLleOBbw=
=Glt1
-----END PGP SIGNATURE-----
next reply other threads:[~2004-07-10 0:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-10 0:43 John Richard Moser [this message]
2004-07-10 2:32 ` Garbage Collection and Swap 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
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=40EF3BCD.7080808@comcast.net \
--to=nigelenki@comcast.net \
--cc=linux-c-programming@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).