Re: Ada GC (Robert Dewar)
10 Feb 1996 00:29:31 -0500

          From comp.compilers

Related articles
[14 earlier articles]
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-10)
Re: Ada GC (1996-02-13)
Re: Ada GC (1996-02-13)
Re: Ada GC (1996-02-13)
Re: Ada GC (1996-02-13)
Re: Ada GC (1996-02-13)
Re: Ada GC (1996-02-14)
[1 later articles]
| List of all articles for this month |

From: (Robert Dewar)
Newsgroups: comp.compilers,comp.lang.ada
Date: 10 Feb 1996 00:29:31 -0500
Organization: Courant Institute of Mathematical Sciences
References: 96-01-037 96-02-043 96-02-077
Keywords: Ada, GC, debug

Hans.J Boehme says

"It also seems to be rare that people outside the research community
are willing to admit how much time they're spending tracking down
memory allocation bugs. Nobody wants to admit to making mistakes."

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.

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.


Post a followup to this message

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