[gclist] other GC services
Fri, 11 Apr 1997 09:40:40 -0400
| 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
| - 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.