From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5d3a1501d97dab65 X-Google-Attributes: gid103376,public From: geert@fozzie.sun3.iaf.nl (Geert Bosch) Subject: Re: C to Ada : a piece of code Date: 1996/09/13 Message-ID: <51a30f$co@fozzie.sun3.iaf.nl>#1/1 X-Deja-AN: 180358631 references: <3231732C.2781@virgoa4.in2p3.fr> <01bb9d61$537fe5e0$2b8371a5@dhoossr.iquest.com> <01bb9e40$d0312d80$348371a5@dhoossr.iquest.com> <514lpk$i0m@fozzie.sun3.iaf.nl> organization: La Calandre Infortunee newsgroups: comp.lang.ada Date: 1996-09-13T00:00:00+00:00 List-Id: 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