RE: locks on X86

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

> From: Anthony Green [mailto:green@redhat.com]
> 
> Jeff wrote:
> > I can't see how you could modify the code at runtime 
> however... if the
> > lock routine is inlined, there could be many occurences of 
> it, and you'd
> > have to arrange for it to be placed in a RW segment somehow.
I think there's no fundamental issue with doing this directly, except that
it may be ugly.

I'm assuming that on X86 we'll usually use hash synchronization.  I believe
there will be exactly two time critical instances of cmpxchg in libgcj (plus
a handful in the GC, but those will probably go away eventually).  They're
both in natObject.cc.  We could identify those with distinct global labels,
by turning the appropriate inline function into a macro.  This stuff is
currently all in natObject.cc anyway.

I believe that mprotect is capable of turning a page in the text segment
into a writable, copy-on-write page.  The cost of this would be unsharing
one or two pages, not a big deal except possibly in embedded environments.
Ld.so presumably already plays this game if it has to relocate something in
a read-only segment?
> 
> ld.so will already look for libraries in different 
> directories depending on
> the target system (i686 -vs- i386, for instance).  Perhaps we 
> could convince
> Ulrich that adding support for uni- vs multi-processor 
> targets is a good
> idea and then simply `multilib' libgcj.so.  Maybe it already 
> does this.
> Glibc always surprises me!
> 
That would certainly be nicer.  But we would need to factor out the small
piece of libgcj that's affected.  We don't want to have to distribute 2
copies of the full libgcj.so.

Hans