[gclist] Java vs. ML, particularly GC

[David F. Bacon]

in particular, only two bits are needed per object for the hashcode in almost
all cases.  these bits represent three states: unhashed, hashed, and
hashed&moved.

if an object's state is "hashed" and it is moved by the collector, then the old
address is copied to the end of the new object and the state is changed to
"hashed&moved".  since most objects die young, and most objects don't have
their hashCode() method invoked, this almost never happens.

we implemented this optimization as part of the thin locks work (see pldi98).
there is no inherent reason why a copying collector for java should perform any
worse than for other languages.  

david

p.s. dylan's hashcode semantics are a heinous.