[gclist] Java vs. ML, particularly GC

[Eliot Moss]

>>>>> "Krishnaswami" == Krishnaswami, Neel <neelk@cswcasa.com> writes:

    Krishnaswami> Yes. The hashcode() method on the Object class in Java
    Krishnaswami> makes it very hard to write a high-quality garbage
    Krishnaswami> collector for the JVM, since it makes it very hard to
    Krishnaswami> write a copying or generational collector.

    Krishnaswami> The problem is that every object must return a meaningful
    Krishnaswami> hash code, *and* the Java spec requires that the hash
    Krishnaswami> code of an object cannot change during the run of a
    Krishnaswami> program. The simplest implementation of hashcode() is to
    Krishnaswami> cast the address of the object to an integer and return
    Krishnaswami> that, and with this implementation the constant-hashcode
    Krishnaswami> requirement will be violated by any moving garbage
    Krishnaswami> collector.

Many reasonable Java systems have copying collectors. They assign a hash
code to objects, usually as needed, and STORE IT IN THE OBJECT. A variety
of papers suggest how to use the same space to do this that one uses for
monitor locks on Java objects. The implementation is not difficult, but it
does increase the size of Java objects. However, if an object can have a
lock on it, etc., then the size would likely increase, too.

The usual space overhead for Java objects is thus 2 words: 1 word for the
class information (needed for class-based dynamic method dispatch), and 1
word for hash/lock info. Arrays have an additional word of overhead for
their size (other objects' size can be determined from their class).

Yours in VM education :-) ....			       Eliot Moss