[gclist] Java vs. ML, particularly GC
Fri, 22 Dec 2000 14:25:44 -0600
Krishnaswami, Neel wrote (Fri, Dec 22, 2000 at 02:50:44PM -0500) :
> Yes. The hashcode() method on the Object class in Java makes it
> very hard to write a high-quality garbage collector for the JVM,
> since it makes it very hard to write a copying or generational
> The problem is that every object must return a meaningful hash
> code, *and* the Java spec requires that the hash code of an
> object cannot change during the run of a program. The simplest
> implementation of hashcode() is to cast the address of the object
> to an integer and return that, and with this implementation the
> constant-hashcode requirement will be violated by any moving
> garbage collector.
> I'm sure there's trickery you can use to get around this
> restriction in Java, but it's a serious enough problem that
> most Java implementations simply punt and use a simple mark-and-
> sweep garbage collecter. This kills gc performance compared
> to the collectors in other advanced functional and OO languages.
I don't see why implementations have to stick to
"use-pointer-as-hashCode" solution. I think some
implementations reserve some space in each object
to store the hashCode, in which case the allocator
could put in an object-ID (maybe coupled with
a thread-ID for multithreaded allocators). Or use
the object creation time + thread-ID.
There should be some tricks you can play to reduce
this space overhead but I'm sure there are many
Java implementations out there today which use
something better than stop-the-world mark-and-sweep.
Though I don't know how many of these have
made their way into commercial products.