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) |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.