Re: Garbage collection for system programming

torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
28 Feb 2005 19:48:49 -0500

          From comp.compilers

Related articles
Garbage collection for system programming sheath1@gmail.com (Simon) (2005-02-28)
Re: Garbage collection for system programming torbenm@app-4.diku.dk (2005-02-28)
Re: Garbage collection for system programming Martin.Ward@durham.ac.uk (Martin Ward) (2005-02-28)
Re: Garbage collection for system programming richard.xian@gmail.com (Richard Xian) (2005-03-01)
Re: Garbage collection for system programming nmm1@cus.cam.ac.uk (2005-03-01)
Re: Garbage collection for system programming sheath1@gmail.com (Simon) (2005-03-01)
Re: Garbage collection for system programming torbenm@app-4.diku.dk (2005-03-04)
Re: Garbage collection for system programming pault@dessci.com (Paul Topping) (2005-03-04)
[1 later articles]
| List of all articles for this month |
From: torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 28 Feb 2005 19:48:49 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 05-02-104
Keywords: GC
Posted-Date: 28 Feb 2005 19:48:49 EST

"Simon" <sheath1@gmail.com> writes:




> Anyway, what I was wondering is this: How feasable is it to use a
> garbage-collected language for low-level tasks like writing operating
> systems, device drivers, memory allocation systems, and basically
> anything else you would HAVE to write in C instead of, say, Objective
> Caml.


The Fox Project at Carnegie Mellon (http://www-2.cs.cmu.edu/~fox/) has
explored using functional languages for systems software, trying to
get the imporved safety of typed functional languages without losing
sight of efficiency issues.


As John said, the real problem is not so much space overhead for
tagging etc., but real-time constraints. State-of-the-art GC
techniques are good enough for soft realtime without introducing an
unacceptable overhead. For hard real-time, you can use region
inference
(http://www.cs.cornell.edu/Nuprl/PRLSeminar/PRLSeminar99_00/Walker/nov8.html),
which replaces GC with an automatic stack-like allocation/deallocation
mechanism.


                Torben


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.