Re: "No aliasing = no garbage collection"

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Ovind asked:

>    Tom Locke (PhD student au UKC) said something like "if we 
>    remove aliasing, we also remove garbage collection, because
>    we will not have non-parental objects floating around."
> 
>    A somewhat weaker predicate might be "if we have aliasing
>    under control, GC may also be under controll, in a predictive
>    way." Is this true? Objects would still be taken from the
>    heap, the heap would still be fragmented and a need to 
>    defragment it would arise? Or could objects be taken from
>    the stack (possible in RT-Java) in that case? 

Tom discussed the various and very different ways in which we use references
in OO systems.  These differences are alarming for what seems to be the same
mechanism - he showed examples where that mechanism causes great harm (e.g.
by breaking data encapsulation and making component based design unsafe).

One major class of the use of references can be put under occam-like alias
control - not all, of course (e.g. for graph data structures like doubly
linked lists).

Those that can be controlled are guaranteed to only have one reference.  When
that reference is lost (e.g. overwritten) the space for that object can be
automatically de-allocated.  Using Brinch-Hansen's algorithms for parallel
recursion workspace allocation - as modified by David Wood and presented in
his paper at CPA 2000 - alias controlled single reference objects can be
allocated and de-allocated in *unit* time with an average space wastage of
only 25% ... which looks like a big win for real-time systems ...  the new
rt-java draft specification for a real-time Java API just ducks the whole
issue (they have unit time allocation and *no* de-allocation - if I follow
it right - which is going to lead to memory efficiency problems or very
tedious user code to get around it) ...

But alias control can't be done with Java or C# or ... a better language is
needed that takes these issues seriously.

Peter.