RE: libgcj and the NPTL posix threads implementation

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

Anything we can do to speed up _Jv_ThreadSelf is good.  My recollection
is that on X86, pthread_self started using a segment register before
NPTL.  It is probably a good idea to remove the SLOW_PTHREAD_SELF definition.

I'm not quite sure what the best replacement is, though.  You were suggesting
just using the segment register directly?  That avoids the dynamic library
call, and is no doubt the fastest, though a bit ugly.  And it probably ports
to systems where other parts of the tool chain don't fully support __thread tls.
I'm not sure how many systems are in that category.  Calling pthread_self()
is cleanest, but I think still involves a dynamic library call.

On the other hand, the recursive mutex issue is different.
With hash synchronization, _Jv_MonitorEnter should not invoke any
pthreads routines (except possibly pthread_self()) on the fast path.
Thus I think this should be a very minor optimization.  Since the current
code is no doubt more portable, I'm not sure it's worth it.  If pthread_mutex_lock
shows up near the top of a profile, I'd like to know about it.  (The critical
operations should be computing the thread identity and compare_and_swap.  The
latter is a single instruction, but it may take a long time, even for a
cache hit.)

The other optimization opportunity here is to refactor the code so that the
compiler can pass some state between _Jv_MonitorEnter and _Jv_MonitorExit.
Currently there is some duplication between the two, and _Jv_MonitorExit verifies that
the current thread holds the lock.  The compiler already knows
that in most cases.  It may even be reasonable to inline the fast path
of _Jv_MonitorExit if _Jv_MonitorEnter returns a pointer to the lightweight
lock, and can prove that the lock is held (e.g. if we're compiling from Java
source).

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Michael Koch
> Sent: Friday, February 27, 2004 7:48 AM
> To: Anthony Green; java@gcc.gnu.org
> Subject: Re: libgcj and the NPTL posix threads implementation
> 
> 
> Am Freitag, 27. Februar 2004 16:39 schrieb Anthony Green:
> > Recent glibc based systems are often bundled with a new 
> posix threads
> > implementation called NPTL (vs the old linuxthreads implementation).
> >
> > I believe that the NPTL code has been shaken out enough now that we
> > should start taking advantage of it.
> >
> > For instance, our posix-threads.h says:
> >   // For compatibility, simplicity, and correctness, we do not use
> > the native // pthreads recursive mutex implementation, but simulate
> > them instead.
> >
> > It looks like NPTL contains a working version of recursive mutexes.
> > Using them will save a lot of work in what is probably one of our
> > most frequently called runtime function (at least one additional
> > function call and some tens of
> > instructions).
> >
> > I propose we just...
> > #define _Jv_Mutex_t pthread_mutex_t
> > ...on NPTL enabled systems, and make appropriate changes.
> >
> > The one catch is _Jv_MutexCheckMonitor(_Jv_Mutex_t *), which is a
> > sanity checker and wants to look at the mutex owner.  Is it safe to
> > ignore this?
> >
> >
> > We define SLOW_PTHREAD_SELF for many Linux systems.  If you look in
> > posix-threads.h, this forces us to fall back on a clever caching
> > scheme.  However, for x86 Linux I believe _Jv_ThreadSelf may now be
> > implemented as a single machine instruction (a recent minor ABI
> > change to support thread local storage (TLS) makes this possible).
> >
> >
> > I'm certain there are other areas where we may take advantage of the
> > NPTL and TLS given a few more minutes of looking.  However, I'm not
> > sure how best to handle the configury aspects.  Do we want a global
> > NPTL test and #define?   This seems like the simplest approach.  I'm
> > not even sure there's an easy way to detect NPTL-ness.  Perhaps we
> > should just look at at the glibc version and make an assumption. 
> > Opinions?
> 
> Would looking at glibc version be enough ? I know at least on Debian 
> based systems NPTL/TLS only works with Linux kernel 2.6.x but 
> not 2.4.x 
> or older systems.
> 
> 
> Michael
>