Re: Garbage Collection in Ada

[lars.farm@ite.mh.se (Lars Farm)]

I said:
> "I'm genuinely puzzled and simply trying to figure out which of the
> conflicting views is right: (1) my limited experience combined with
> others claims that the set of falsely retained pointers is relatively
> small. A small, perhaps negligible problem. or (2) Your claims that this
> is a serious error that likely will make my program fail. The views
> simply don't match. I need more information."

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> That is a complete misreading of what I said, please go to an archive and
> reread the thread! I never said that it would "likely" make your program
> fail.

Ok. On doing so (see below) the impression I get is that I should expect
a crash per week.

A program that crashes once a week will be thrown off my disk because I
would consider it seriously broken. A program that crashes once per 3000
years would for many users be a negligible problem. At that rate there
are other bugs that will dominate in any work performed by humans.
Program development is still a human activity. This difference in
magnitude could illustrate the two conflicting views I mentioned. 

By the way, not every program guides missiles or airplanes. Some
programs have extraordinary stability requirements. This type of program
obviously needs more work than others. GC probably also has positive
effects on stability even for this kind of program. Simpler design leads
to fewer bugs, programmer induced faults. There is a break even point.


> Message-ID: <dewar.845505704@merv>

> Finally, there is one disadvantage of a conservative collector
> that you did not mention, namely the possibility that it will
> unexpectedly collect blocks that are in use.


> Message-ID: <dewar.845608007@merv>

> Are there really programs that count on conservative GC working? Well
> perhaps so. For example, Microsoft Word, at least the version I use,
> sometimes leaks memory, and just possibly this is a data dependent
> effect if it uses conservative GC, since it could be that if certain
> words are in your document, you are unlucky and some storage does
> not get freed.
> 
> Similarly you can imagine a command interpretor which works most of the
> time, except when a certain person logs on, because their password
> causes a critical section of storage not to be freed.


> Message-ID: <dewar.845747957@merv>

> I would say that relying on a conservative
>     garbage collector NOT to get unlucky is something that you 
>     can afford to do in one-off programs that don't need to be 
>     reliable, and perhaps even in typical PC software (so what 
>     if the word processor crashes once a week - that seems to be 
>     what people expect anyway).


>Message-ID: <dewar.845247229@merv>

> Just one point, virtual origins are not a problem at all in a proper
> garbage collector, only in approximate "conservative" ones, which are
> not so conservative and are happy to remove blocks in use if virtual
> orgins around. The technique of using virtual origins can perfectly
> well be used in C (see the sources of gigi for an example of this use).


>Message-ID: <dewar.845470185@merv>

> Well if your requirements here are so weak that you find that these
> kind of conservative GC's are acceptable, then what's your problem, 
...
> If you count on  a conservative
> collector to free storage, you have a very unreliable program, since 
> you could find on some particular run that you were just unlucky and
> a junk integer value held a critical large block in memory, causing
> the program to crash and burn. 


> Message-ID: <dewar.845559504@merv>

> 3. You cannot require blocks to disappear, since if you have conservative
> collectors in mind they do not guarantee to free even a single block in
> a given program.


> Message-ID: <dewar.845840549@merv>

  (comparing hashtable hazards favorably to conservative GC hazards)

> Well not so intolerable, there is a big difference btween compiling one
> program slower by a relatively small linear factor, and blowing up in
> an application at runtime because you ran out of memory. As I said

> Message-ID: <dewar.845809398@merv>
> Actually, as I have noted before, I am dubious about real
> applications depending on conservative GC,
















-- 
Lars Farm, lars.farm@ite.mh.se