Re: Garbage collection for system programming

torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
4 Mar 2005 14:13:11 -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)
Re: Garbage collection for system programming nmm1@cus.cam.ac.uk (2005-03-04)
| List of all articles for this month |
From: torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 4 Mar 2005 14:13:11 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 05-02-104 05-02-109 05-03-011
Keywords: GC, practice
Posted-Date: 04 Mar 2005 14:13:11 EST

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


> Posted by Torben Ęgidius Mogensen, Feb 28, 4:48 pm:
> > 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.
>
> Oooo. Interesting; I only vaguely recall ever hearing about this. I
> shall have to look into it; it might be worth putting into a later
> version of my language. It depends on how much complexity it adds to
> the compiler and runtime, I suppose, but we shall see.


It adds considerable complexity to the compiler, but the runtime
system is fairly simple, in fact simpler than if you use GC, as you
don't need to allocate room for GC tags with heap-allocated objects
and you don't need to keep track of your root set.


Also, region-inference requires a good type system to work as well as
reasonably clear evaluation order. Some of these restrictions may be
overcome by adding some runtime reference counting (of regions, not
individual objects) rather than letting region lifetime be determined
by program structure, see
http://www.diku.dk/forskning/topps/bibliography/2001.html#D-455 . To
quote the abstract:


"We present a unified Floyd-Hoare Logic inspired region type system
for reasoning about and inferring region-based memory management,
using a sublanguage of imperative region commands. Our system
expresses and performs control-sensitive region management without
requiring a stack discipline for allocating and deallocating
regions. Furthermore, it captures storage mode analysis and late
allocation/early deallocation analysis in a single, expressive,
unified logical framework. Explicit region aliasing in combination
with reference-counted regions provides flexible, context-sensitive
early memory deallocation and simultaneously dispenses with the need
for an integrated region alias analysis."


If you want to have concurrency in your language, you should
definitely go for the reference-counting version instead of the
stack-disciplined structure-based version, as concurrency makes it
almost impossible to keep track of region lifetimes at compile-time.


                Torben


Post a followup to this message

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