[gclist] Java vs. ML, particularly GC

[Manoj Plakal]

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
> collector. 
> 
> 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. 
>
>  [snip]
>
> 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.

	Manoj