locks on X86

Mon Mar 12 17:09:00 GMT 2001

> 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