[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Aliasing and Garbage Collection
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