Re: C to Ada : a piece of code

[geert@fozzie.sun3.iaf.nl (Geert Bosch)]

Robert Dewar said, regarding virtual origins and conservative GC:

`` Nothing to worry about, obviously the use of virtual origins is only
   possible with fat pointers. So just use thin pointers for your
   garbage collected environment. ''

I'm integrating the garbage collector by replacing the malloc function,
so ultimately all heap memory is allocated through my own allocator
that cooperates with the GC.  By doing this the GC is able to quickly
find out the following, given some pointer-like value:

  * Whether it points to or inside (!) a heap object or not
  * If it is a valid pointer:
     * What is the size of the heap object
     * What is the first address occupied by the heap object
     * What are the attributes of the heap object

This information is necessary to write an efficient garbage collector.
If the user stores an access-value to a garbage collected object in 
non-garbage collected memory, the GC has to find that value or it
might remove an object that is still accessible, leading to erroneous
behavior.

The only other alternative would be to keep all garbage collected
objects that happen to have a pointer-like value somewhere in non
garbage-collected memory. However any GC implementation using that
approach will not be of any use because it will trace pointers that
are not reachable anymore. A bad GC is worse than no GC, IMHO.

All conservative garbage collectors I know use a cooperating allocator
that makes it possible to find out the information listed above.

As I found out during my research, it is perfectly possible to add a
very efficient garbage collector to GNAT with only some very small
changes to the run-time library. Hopefully this situation won't be
changed by a small optimization like using virtual origins.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943