[gclist] Java vs. ML, particularly GC
David F. Bacon
Fri, 22 Dec 2000 15:59:53 -0500
in particular, only two bits are needed per object for the hashcode in almost
all cases. these bits represent three states: unhashed, hashed, and
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.
p.s. dylan's hashcode semantics are a heinous.