[gclist] Compiler improvments to help garbage collection.

[Charles Fiterman]

At 09:59 AM 8/7/97 -0400, David Chase <chase@world.std.com> wrote:
>At 08:14 AM 8/7/97 -0500, Charles Fiterman wrote:
>>The other thing that struck me about the article is that instead of
>>trying to maximize inlining of storage it might make sense to divide
>>leaf objects, objects without pointers, from all pointer objects. This
>>would mean a conservative collector was suddenly absolute and pages
>>with leaf objects still don't get touched during collection. It looks
>>like a good experiment.
>
>This has been tried in the past.  The Boehm-Weiser collector has,
>or had, two allocation entry points, and the Olivetti Modula-3 compiler
>would allocate pointer-free data structures using the pointer-free-
>storage collector.  This doesn't solve the problem for the stack,
>and "mixed" (pointer and integer) data structures are still mixed.

The point is that this is a language article not a collector article.
The language gets user descriptions of classes and says you really
don't want these for data structures. I can inline these things. While
it is doing that it can divide all data structures into leaf and all
pointer. This means there are no mixed data structures and the collector
knows which is which. 

While the Boehm-Weiser collector was designed for an uncooperative 
environment it still works better in a cooperative one. Having the 
language do that means the conservative collector is suddenly an 
absolute collector. Nobody's social security number gets mistaken for a 
pointer. Ordinary collections will never scan anything but pointers
and those will be on pages with nothing but pointers. Further we can
have compaction passes where objects get moved and pointers changed.

While Boehm-Wiser is intended for uncooperative environments it has
some advantages for cooperative environments that want to use it.
For example being able to take any address within an object and get
the address of the object simplifies a lot of OO implementation problems.

As far as the stack I would love to make that an antique notion. If
we can inline allocation of objects we can inline allocation of stack
frames even easier. All the execution frames of all the things this 
frame calls purely lifo get put in the same place. Those execution frames
do the same. So execution frames are only allocated at run time where
their use is not purely lifo.

This combines the ultimate in generality, execution frames are ordinary
objects, with the ultimate in efficiency, execution frames are not
allocated or freed at run time. Running a function means putting
its execution frame's object type in the right place, then putting its 
parms in the right places, then sending it a series of messages one of 
which can be run yourself. The right place can be newly allocated 
storage or storage in the current execution frame. The part about
putting the object type in the right place could be partially evaluated
out for functions called from loops or even partially evaluated out
to put the information in static storage at compile time.



			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A young man saw a product advertised in a magazine that said
"Guaranteed 100% effective against bugs when properly used."
He sent away and got two blocks of wood with the instructions
"Place bug on block A, strike sharply with block B." Debuggers
are like that, and you can get stung while using them. Great
Circle tries to be something better than that.