[mercury-users] Automatic Recognition of Uniqueness

[Peter Schachte]

On Thu, Sep 10, 1998 at 12:21:27PM +1000, Andrew Bromage wrote:

> There are actually two things that I've heard called "compile-time
> garbage collection".
> 
> The definition that might spring to mind first is freeing up memory
> (i.e. inserting free()-like operations into the generated code) for
> structures which are known to be globally dead.
> 
> From an implementation point of view, freeing up memory in this way
> only really makes sense if you're using a malloc-style allocation
> scheme, where you actually _can_ free structures.

This seems to be assuming that the compiler can only use one memory
management strategy, which isn't true.  For example, in the code

	... X=[U|V], p(..., X, ...), ...

if the compiler can determine that neither X nor any term that it may
be aliased to is not used after the call to p, then the compiler can
allocate X on the call stack instead of the heap, so it will be
automatically reclaimed after this clauses completes execution.

Alternatively, in a program:

	..., p(...X...), ..., q(...X...), ...

where p binds X and the compiler can determine that (some of) X cannot
be accessed after the call to q, the compiler can generate a
specialized version of p that allocates the memory for X in a special
heap which is managed by explicit allocation and freeing, and then
generate a call to free the parts of X that cannot be accessed.

There's no reason (other than complexity of the compiler) that Mercury
can't use several memory management schemes.  Ideally, runtime garbage
collection would be reserved for only the hard cases.


-- 
Peter Schachte                | How does a project get to be a year late?
mailto:pets at cs.mu.OZ.AU       | ... One day at a time. -- Frederick Brooks,
http://www.cs.mu.oz.au/~pets/ | Jr., The Mythical Man Month 
PGP: finger pets at 128.250.37.3 |