Re: Garbage collection (was a spinoff of a spinoff of a GA

[jsa@alexandria (Jon S Anthony)]

In article <EACHUS.96Oct24211243@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> 
> In article <JSA.96Oct22152111@alexandria> jsa@alexandria (Jon S Anthony) writes:
> 
>    > > 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: ...
>    >	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)
> 
>    You must have been smoking some good stuff.  Precise collectors can
> do the later, but never the former. Think for a second, any reclamation
> the garbage collector can do, the free routine can do as well, without
> the memory scan for live references.

Nah, you're in the weeds  for several reasons.  Hans Bohem did a good job of
listing many.  No need to repeat them - just read them.


>   > > 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, ...
> 
>     Let's take the absolute best example of a structure that "requires"
> garbage collection an arbitrary graph consisting of nodes with
> arbitrary numbers of edges, and cycles allowed.  Had to implement one
> of those recently, and the requirements allowed nodes to be moved from
> one graph to another.
>
>    The finalization routine took five lines, and neat trick was in the
> Adjust routine.

What "adjust" routine?  When you have limited types you don't even
_have_ adjust.  Besides, "adjusting" still reflects a value semantic
mentality and that is not always what is needed (in fact it is often
not what is desired).  Do you prevent a client from allocating one of
these nodes?  Assigning that access result to some access variable?
On the stack?  Or maybe in a field of a variable of another structured
type?  What about those references?  You can't have "controlled access
types".  Yes, you can hack a clumsy, heavy weight version which in the
end just kicks the problem up one level anyway.

I don't see the relevance of what you are trying to say here.

> From a garbage collection point of view it was "extra overhead" but

Yes.


> it allowed me to do other operations such as reachability more
> efficiently.
???????

>  (You can't reach a node with a lower absolute generation number.
> The biggest win is that you only have to check against nodes you
> have visited before with the current generation number.  Beats
> marking and unmarking and allows more than one such operation to be
> conducted simultaneously.)

What makes you think that is the only, let alone the best, option????


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