libgcj and the NPTL posix threads implementation

Fri Feb 27 15:39:00 GMT 2004

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?
Thanks,
AG
-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.