Re: Ada GC

dewar@cs.nyu.edu (Robert Dewar) writes:


>Tracking down memory allocation bugs is NOTHING compared to tracking
>down garbage collection related bugs caused by the use of low level
>features that are capable of destroying the consistency of data on
>which the GC depends (believe me, I have spent a lot of time doing
>this for SPITBOL programs -- now in SPITBOL, such low level happenings
>can only occur in the presence of included assembly language, but both
>C++ and Ada deliberately have low level features with these kind of
>destructaive capabilities built into the language.


My experience has been that this is very dependent on the garbage
collector and the discipline used in taking advantage of the low level
features. I don't recall ever hearing such complaints from Cedar
users. (Cedar clearly identifies unsafe code. Objects are not moved
by the collector. A conservative collector has been used since C
interoperability became an issue.) Such problems also seem to be
fairly rare with Modula-3, though I have heard of one problem caused
by an object moving underneath C code. Modula-3 also isolates unsafe
language features.


This was a common problem in the language implementation I was mostly
responsible for (Russell). The runtime system probably still had some
latent GC-communication bugs when I switched to a conservative
collector, at which point such things disappeared. (In this case the
language itself had no unsafe features other than a facility to call
C.)


One of the first uses of the fully conservative collector was with
assembly code generated by student compilers in a compiler course at
Rice. That seemed to work fine.


This is one reason why, in a non-real-time environment, I would argue
for a collector that can handle ambiguous pointers, even if better
information is available. It makes things like C intercallability
easier, and gives you an easy way to debug the information you do
supply to the collector. (Run the collector in fully conservative
mode first. If it still doesn't work something else is broken.
Otherwise add the type information back slowly. Use binary search if
all else fails.)


>Note incidentally that the GC problem is harder in Ada 95 than in Ada
>83, or more accurately, the implemntation freedom is reduced. In Ada
>83, you can only point to the start of an allocated block, but the
>presence of aliased in Ada 95 relaxes that restriction.


>I am not saying that GC is impractical for Ada 95, just that block
>marking algorithms (which are otherwise attractive) cannot be used.


Depending on the collector, it may be essentially free to map pointers
to the beginning of the referenced block. For our collector that's
the case. (Pointer validity checking is a table lookup at the last
stage. Whether or not interior pointers are recognized depends mainly
on how the table is initialized.) I agree that it does constrain
implementation choices, however.


Hans-J. Boehm
(boehm@parc.xerox.com)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.