Re: Patch: replace mutex with object synchronization

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > > > It seems to me that if we adopt Bryce's plan to have gcj emit class
 > > > metadata rather than actual Class objects, then we've added the
 > > > required extra layer of indirection...  Meaning, we can map a given
 > > > .so exactly once, and then simple create Class objects from the .so
 > > > for multiple class loaders.
 > 
 > Yes, that ought to work, I think.
 > 
 > >That might be true, but there's a significant problem: it's important
 > >to be able to access the otable in a single memory access.  At present
 > >that's "mov otable+offset(%ebx),%eax" which gets us quite decent
 > >performance despite the extra indirection, and this is because the
 > >compiler helpfully reserves a register for us to use as a static base
 > >pointer.
 > 
 > Andrew, I'm not suggesting we change the way offset tables are accessed 
 > by our code at all.

But Tom is.  If the same class binary is to be used more than once,
its otables will be resolved differently in each class loader context:
that means they can't be common; and that means they can't be
statically allocated; and that means they can't be accessed in the way
they are at the moment.

 > The idea is, instead of having the compiler emit a complete 
 > java.lang.Class object containing method pointers and tables of pointers 
 > to Utf8 strings and such, we emit a single block of data containing that 
 > info in some structured way which the runtime understands. This should 
 > hopefully save a lot of space in the binary 

I understand that, but Tom is talking about something different:
re-using the same object in different class loaders.

 > and a lot of dynamic linking time.

Well, that remains to be seen.  We need to be very careful not to
increase startup time.

Andrew.