Patch: replace mutex with object synchronization

[Bryce McKinlay]

Andrew Haley wrote:

> > 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.
>  
>

I see. Yes, that would certainly be a problem if the otable entries 
resolve to different classes in each context. Is loading multiple 
instances of the same class (in the same binary) into different class 
loaders a common requirement?

> > and a lot of dynamic linking time.
>
>Well, that remains to be seen.  We need to be very careful not to
>increase startup time.
>  
>

Its pretty amazing how many symbol string comparisons occur when loading 
a large C++ program. Uli Drepper's paper has some statistics:

http://people.redhat.com/drepper/dsohowto.pdf

Example: 1.7 million string comparisons to start up OpenOffice.org, with 
an average symbol length of 58 characters. This is aggrivated due to the 
large number of .so's, but a large Java program linked against libgcj.so 
is probably not all that far removed from these numbers.

Its hard to imagine that we can't do better(*), especially since we only 
link a small percentage of the classes in libgcj.so for the average 
program. But, I agree that before making this the default, we need to 
demonstrate a performance improvement, or at least a decrease in binary 
size/memory footprint with no performance degradation.

(*) Then again, there is prelink. It may be hard to beat that. But it 
may still be worth it if we can significantly reduce binary size.

Regards

Bryce.