comp.lang.ada
 help / color / mirror / Atom feed
From: jsa@alexandria (Jon S Anthony)
Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA
Date: 1996/10/22
Date: 1996-10-22T00:00:00+00:00	[thread overview]
Message-ID: <JSA.96Oct22152111@alexandria> (raw)
In-Reply-To: 9610211427.AA06636@most


In article <9610211427.AA06636@most> "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

> Let me put my question another way:
> 
> What are the pros and cons of the following three choices?
> 
> Choice One (in the spec):
>   Declare a data type.  Put a comment on it saying
>   -- Make sure you put calls to the cleanup routines in in every place
>   -- where an object of this type might leave scope.  Make sure you
>   -- put an exception handler in every routine that declares one of these,
>   -- or else ensure that no exception can occur.  And better guarantee that
>   -- exceptions cannot occur in declarative regions.

Pro: Can be done at C level language constructs (simple RT impl. model)

Con: Low level => usually broken (i.e., unlikely that person can keep track
     of this level of bookkeeping for anything beyond a trivial program).
     That is, complex/complicated user (programmer) model.
   
     The sort of thing that generally results in a) leaks, b) dangling
     references.

     Requires a lot of manual futzing and checking (language offers no
     real help).  You're on your own.

     Also, just doesn't work in some situations (without
     amending the various "make sures")


> Choice Two (in the spec):
>   -- If you intend to use this data type, you had better ensure that your
>   -- compiler has a good garbage collector, or get an add-on that can
>   -- work with your compiler's allocation methods.

Forget the "add-on" - that will at best be a conservative collector.  For
the precise collector:

Pro: You need not worry about memory management at the programmer's level.
     Frees you, the human, to worry about more important things.

     Higher level of abstraction (simpler user model)

     More robust in non trivial programs since it does not rely on human
     bookkeeping

     Faster - allocations can be _much_ faster and collections can be
     much more efficient than good ol' "free".

     Works across the board (no need for special casing various situations)

Con: Requires more of vendor => more $$ could be involved in purchase and
     support.  Of course the same is true for _ANY_ high level construct,
     such as tasking, generics, etc.  But I am more than willing to pay
     more for a language/impl that supports these because in the long run
     it is _CHEAPER_.

     Can potentially fool you into thinking that you don't need to know
     anything about what is going on at this level and thereby you could
     end up wondering why your stuff isn't working quite like you thought.


> Choice Three (in the BODY):
> 
>    procedure Finalization (...) is
>    -- this will ensure that cleanup cannot be forgotten.

Pro: Works better than nothing (which is choice one above...)

Con: Doesn't work everywhere

     Expensive (in time and space)

     Requires you to roll your own managers per type per application (but
     in those cases where it doesn't work, need to augment with other stuff
     - e.g. your own storage pools and management...)


> What are the cases Finalization doesn't cover?  (Other than those the
> programmer DECIDED not to apply it to.)

Lots's of places.  Finalization works pretty darn well for _stack_
allocated things, but pretty poorly (even not at all) for long lived
shared heap allocated things.  Since the latter are very important in
most large scale programs of any note, ...


> And what is so hard about "roll your own"?  After all this argument about
> how and why this and that type of collector can bite you on the behind,
> how can anyone complain that

What's so hard about rolling your own tasking model on top of the base
thread package of your OS?  What's so hard about rolling your own
polymorphic dispatching model on top of variant programming
constructs?  What's so hard about using the OS file system directory
structure for hierarchical subsystems?  You get the picture.  GC
really is this fundamental a construct.

Collectors won't bite you on the behind if they are precise and offered as
part of the total package from the vendor.


> is so difficult.  Sure, the compiler might fail to call it, but we have
> better ways of dealing with naughty compilers than adding on outside tools
> of arguable value.

It may fail to be called not because the compiler is wrong, but because
you Joe Programmer got the bookkeeping wrong.  Worse - it may be called
when it should NOT be called for the same reason.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com





  reply	other threads:[~1996-10-22  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-10-21  0:00 Garbage collection (was a spinoff of a spinoff of a GA W. Wesley Groleau (Wes)
1996-10-22  0:00 ` Jon S Anthony [this message]
1996-10-25  0:00   ` Jon S Anthony
1996-10-27  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA diatribe) Robert Dewar
1996-10-25  0:00   ` Garbage collection (was a spinoff of a spinoff of a GA Robert I. Eachus
1996-10-24  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA diatribe) Hans-Juergen Boehm
1996-10-25  0:00       ` Robert A Duff
1996-10-25  0:00         ` Hans-Juergen Boehm
1996-10-25  0:00     ` Brian R. Hanson
1996-10-30  0:00   ` Jon S Anthony
1996-10-30  0:00     ` Robert Dewar
1996-10-31  0:00   ` Jon S Anthony
  -- strict thread matches above, loose matches on Subject: below --
1996-10-17  0:00 Garbage collection (was a spinoff of a spinoff of a GA W. Wesley Groleau (Wes)
1996-10-20  0:00 ` Robert A Duff
1996-10-21  0:00   ` Michael F Brenner
1996-10-21  0:00     ` Larry Kilgallen
1996-10-21  0:00     ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox