Re: Garbage Collector

[Michael van Acken <KK120y2@mail.lvr.de>]

> > This may be the long term goal.  My short and mid term goal is to
ship
> > oo2c with functional gc support.  Obviously, I cannot ship it
with a
> > hypothetical garbage collector.  And even if OGC exists, I cannot
dump
> > support for Boehm's gc as long as OGC does not support all of the
> > systems supported by Boehm's gc.  You see, this is required _and_
> > desired.  Until then (read: over the next few years, and possibly
> > indefinitely) oo2c will support the conservative gc.  And oo2c/gc
can
> > only implement a fraction of the interface of OGC.Mod.
> 
> How would we practically create a test-bed OOC that could use the
new
> garbage collector and provide the required run-time support?

You simply hack your own copy of oo2c to provide different run-time
data structures.  This is quite easy, you only need to add code to
manage them (e.g. in __oo2c.c), and modify the oo2c back-end to place
the necessary code into the module's init function to create the
run-time information.  Together with the stack info you can build 
your test system.

Once you have a working (robust, well tested) OGC for your test
platform (preferably plus assorted other platforms, e.g. Linux/i386),
I will integrate it into the official oo2c distribution.  This
assumes, that oo2c's configure is able to distiniguish between
platforms with OGC and "Boehm gc only", and can install the proper
variant of oo2c.

> Does anyone know how I would determine the maximum stack address or
> the stack region size?

I only know that some systems allow to adjust this with the ulimit
command.  Until the upper stack limit (e.g., 8MB) is reached, the
stack is grown dynamically.  Sorry, no infos form my side.

-- mva