Re: Aliasing and Garbage Collection

[Denis A Nicole <dan@xxxxxxxxxxxxxxx>]

I only belong to occam-com, so this bounced the first time.  And I don't
really want to join java-threads as I'd then get almost everything twice.

On Tue, 17 Oct 2000, Denis A Nicole wrote:

> > On Tue, 17 Oct 2000, Tom Locke wrote:
> > 
> > > Hi,
> > > 
> > > This is the first of a few posts. A while back a thread kicked off about an
> > > issue I raised in my talk at CPA: A language that has no aliasing has no
> > > need for the runtime overhead of garbage collection.
> > > 
> > > This is a trivial observation - the responsibility of the garbage collector
> > > is to determine when an object is unreachable, in a language with no
> > > aliasing, data objects are referenced by only one pointer, when the pointer
> > > is overwritten, the memory can be reclaimed. The point at which the object
> > > is unreachable is known *statically*, the compiler just inserts the
> > > 'reclaim' code when the pointer is overwritten or goes (permanently) out of
> > > scope.
> > 
> > This is refrence counting with at most one reference. There would be
> > almost no additional overhead in any scheme (eg without circular
> > references) which made reference counting easy. 
> > 
> > There is still a potential problem with fragmentation; you do not
> > eliminate the possible need for free space compaction.
> > 
> > > I am a bit concerned (and hoping that I've misunderstood) by the suggestion
> > > that the overhead of GC can also be removed by simply 'buying twice as much
> > > memory', and not reclaiming anything. In a program with lots of dynamic
> > > allocation, i.e. most programs, especially OO, memory would be leaked very
> > > rapidly, I would imagine most Java code could get through a megabyte in a
> > > matter of seconds. It might work if you buy a million times as much memory!
> > 
> > There are two possible interpretation of this statement. It is relatively
> > easy to reduce fragmentation by allocating data structures in only fixed
> > power-of-two sizes.
> > 
> > There are also some rather complicated real-time garbage colletors
> > (usually involving data copying) which cost a factor of two overhead in
> > memory and give (rather poor) real-time performance guarantees.
> > 
> > > 
> > > CAN WE DO WITHOUT GC ALTOGETHER?
> > 
> > Probably, in a lot of systems. I find it diffcult to get convincing
> > demonstrations of correctness if you rely on GC. There was, for example, a
> > communications controller called a Camtec Pad which was once popular in
> > the UK. It would crash after several months of running. The trouble was
> > that, under some fault conditions, some buffers were not released, leading
> > to slow memory leaks. This is not a GC problem, it is a program bug but,
> > like many of the traps into which occam does not fall, it wouldn't happen
> > in occam. 
> 
> Denis A Nicole                 WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan
> High Performance Computing     Email: dan@xxxxxxxxxxxxxxx
> Department of Electronics      Phone: +44 23 8059 2703
>        & Computer Science      Fax:   +44 23 8059 3903
> University of Southampton
> SO17  1BJ
> United Kingdom
> 
> 

Denis A Nicole                 WWW:   http://www.hpcc.ecs.soton.ac.uk/~dan
High Performance Computing     Email: dan@xxxxxxxxxxxxxxx
Department of Electronics      Phone: +44 23 8059 2703
       & Computer Science      Fax:   +44 23 8059 3903
University of Southampton
SO17  1BJ
United Kingdom