Re: OOC Garbage Collector Proposal

[Tim Teulings <tim@edge.ping.de>]

Hallo!

Some statements, questions...

> The following discussion is based on the ETH Report #156, "Oberon
> Technical Notes", the second note entitled "An Integrated Heap
> Allocator/Garbage Collector" and the fifth note entitled "Garbage
> collection on Open Arrays."

The Oberon-A compiler also implements a gc. It is mainly written in
Assembler (680xx) but as it is fully documented it might be another
resource of information.

> Garbage Collector
> ----------------- 
> Garbage collection consists of a mark and sweep phase.  During the

As far as I know, there are other alogrithms for garbage collection.
Has anybody more information?

> appropriate free list.  The mark & sweep phases need to be
> uninterrupted so that memory references and the stack contents remain
> consistent.

There are also aproaches that work more concurrent, thus avoiding some
temporary "hanging" of the application while gc. Perhaps "Hanging" is
no problem on current machines, but on 680xx is was definitely
existing. How about threads. Since you own a BeBox you must have
thought about it?

> Finalization
> ------------

It could also be possible to assign a finalizer to a class instead to
an object. This may have the advantage, that one need not to register
every object but the class registers itself by adding some compiler
pragma in front of the finalizer procedure. On the other hand different
finalizers for different instances of a class may be usefull?

> OOC Support Required
> --------------------

> offsets of the pointers contained within that record.  Typically this
> list of offsets can consist of a variable-length table which is
> terminated by a negatively-valued sentinel.  The type-descriptor block
> size will obviously depend on this table size.

since as far as I know the type descriptor already owns a
variable-length table (methods) this might be a performance problem,
since the gc has one more indirection to take.

> Secondly, it will be useful to store within a module's descriptor
> block where the module's static data begins and its size.  This start

This could be problematic with the current C backend which has no
single block of memory for module global variables. Perhaps one mus use
an array of void pointers.

> When To Collect Garbage
> -----------------------

I'm definitely against a explite call to the gc, it must be possible to
let the gc be called implecitely. It is very difficult for some long
running or huge ammounts of memory allocating programs to find an ideal
position for garbage collection. Another idea is to put the gc cycle
within the call to NEW but find some other criterium for gc. F.e. the
gc must be called before the real memory (in difference to the virtual
memory) runs out. What about tracing stack for legal object pointers.
Are there any aproaches. It seems to me that this is neccessary for
concurrent calls and its implementation sound difficult.

-- 
Gru...
       Tim.