Jv_AllocBytesChecked (Was: What is wrong with Vector?)

Boehm, Hans hans_boehm@hp.com
Fri Dec 22 10:58:00 GMT 2000

> From: Tom Tromey [ mailto:tromey@redhat.com ]
[Putting lock state on the stack.]
> Hans> I should look at this more.  My impression is that's hard to do,
> Hans> because we don't have a second header word that we could point
> Hans> at the stack allocated structure.
> I think EF uses a single word, by having a bit or two reserved to
> indicate state.  Then whatever extra info is needed is stashed on the
> stack.
I looked at the EF documents briefly.  They need a bigger header, since they
move objects.  Thus they have a hash value in the object, which they can
temporarily replace with a pointer to a stack slot when they lock the
object.  I think we would have to replace the vtable pointer, since that
will be the only remaining header word.  That doesn't look practical, since
we have to support method calls on locked objects reasonably efficiently.

Thus I think we're stuck with hashing to find monitors.  But that in itself
is cheap.  On X86, it's completely dominated by the cost of finding your own
thread id, which you need to allow recursive monitor entry.  (Ulrich was in
the process of changing linuxthreads to keep the thread id in a segment
register.  Anyone know if that's making progress?)

My guess would be that saving the header word will give us a significant
advantage in some cases, and none in others, since objects generally have to
have a size that's an even number of words.  If we manage to reduce the real
object size, then that will impact both cache miss rates and either memory
footprint or GC frequency.  


More information about the Java mailing list