[gclist] other GC services

[Jerry Leichter]

| Has anybody experimented with object-specific copy methods ?
| Since the cost of copying has to be paid anyway, why not take advantage of it
| to do some more work:
| - tree data-structures could take advantage of this occasion to do some
|   rebalancing
| - memoizing-caches could copy themselves as empty-caches or at least reduce
|   their size
| 
| Similarily in a system with memory-hierachies visible to the GC, the "copy to
| disk" or "copy from disk" could be a user-definable method that could do 
| things like getting rid of redundant data (that's only used to speed up 
| access) like back-pointers...

What a nice idea!  Consider its logical extension:  The collector has a 
reference to an object, OldRef.  It will logically replace all occurances of the 
reference with NewRef.  Traditionally, we think of this as a simple relocation 
operation - the same bits are moved from the memory at OldRef to the memory at 
NewRef.  But really all that matters is that NewRef and OldRef have the same 
semantics.  Rebalancing a tree is an example in which the bits are very 
different, though the implementation remains the same.  But one could even chose 
a different implementation.  This might be particularly interesting with a 
generational collector:  Young objects might have an implementation that made 
updates faster at the expense of memory or read accesses.  Old objects might 
have an implementation that favored read accesses.

The big problem would be debugging.  A bug in a copy procedure would manifest 
itself at arbitrary points in the program; it might be very hard to find.  Only 
experience would tell us how the hazards and advantages trade off.

I can't recall ever seeing anything like this.  There are obvious analogies to 
user-defined marshalling and unmarshalling procedures.  A remote relative - 
really just a similarity of spirit - at the other side of the GC so to speak, 
appeared in the original APL\360 system.  An APL\360 workspace consisted of a 
block of memory divided into three pieces:  A fixed-size hash table at the top; 
a downward-growing stack below that; and an upward growing heap.  The heap was 
garbage collected when stack and heap bumped into each other.  (This was a very 
simple GC, since each head object was pointed to by 0 or 1 pointers.)  Just 
before swapping a workspace out to disk, a GC was run; then the "hole" between 
heap and stack didn't have to be written.
							-- Jerry