[gclist] object identity & copying collection

[Fergus Henderson]

Mark Tillotson <markt@harlequin.co.uk> wrote:
> So a moving collector is really moving the onus of maintaining the
> mapping back to where it belongs, the hashtable code (and thus
> ultimately to a slot in every object you want to be able to hash
> on...).  Heaps with static objects clearly allow the "identity == 
> address" optimization at the expense of fragmentation.  (Incidentally
> the cost of fragmentation is surely more than one word per object?)

Good question.  With the Boehm (et al) collector, 
is there a simple way of measuring the cost of fragmentation?

> You could also, by assigning integers sequetially on allocation,
> provide a mutator-visible primitive for comparing the ages of objects
> - though offhand I can't think of a compelling use for this outside
> the GC.

In logic programming, this functionality is very useful for trailing
(recording updates so that they can be undone on backtracking).
You save the current timestamp at each choice point, and then
whenever you update an object, you compare the object's timestamp
with the timestamp at the most recent choice point; only if the
object is older than the choice point do you need to trail the update.

Systems with support for transactions might also have similar needs.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.