RE: Hash locks and pointer-free allocation

["Boehm, Hans" <hans_boehm at hp dot com>]

Bryce -

Currently very few kinds of objects are allocated as pointer-free.
Basically it's just certain Strings and primitve arrays.  I agree that in
general we also need to know that the vtable is somehow permanent.  But my
impression is that system calls generally write to primitive arrays or
outside the heap.  Also primitive arrays and strings probably make up a
large fraction of many Java heaps.  So the special cases are important.

I also agree that we could use pointerfree allocation without hash
synchronization if we used an IBM-style bimodal locking scheme in that case.
But that would take work.  It might also significantly increase the number
of finalizable objects in a few cases, since Object.wait() presumably forces
lock inflation.

Hans

-----Original Message-----
From: Bryce McKinlay
To: java@gcc.gnu.org
Sent: 12/7/01 6:13 PM
Subject: Hash locks and pointer-free allocation

I don't think that hash synchronization is neccessarily a prerequisite 
for having pointer free objects specially allocated.

Firstly, no Java object is ever _really_ pointer-free, because of the 
class descriptor (vtable) pointer. I suppose the GC assumes that pointer
free classes themselves are never GC-allocated? Thats no problem for 
things like primitive arrays (and perhaps all native classes), but not 
marking the vtable will prevent Class GC for classes loaded from 
bytecode with a custom classloader.

Even without hash synchronization we can still have pointer free 
allocation provided the "fat" synchronization info data is allocated as 
uncollectable. We can free them using finalizer chaining on the monitor.

I don't think this would be much of a performance hit because "fat" 
locks would only occur for contended monitors and they are very rare.

regards

Bryce.