Segment Register thread descriptor (was Re: Jv_AllocBytesChecked)

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Jeff Sturm wrote:

> "Boehm, Hans" wrote:
> > Thus I think we're stuck with hashing to find monitors.  But that in itself
> > is cheap.  On X86, it's completely dominated by the cost of finding your own
> > thread id, which you need to allow recursive monitor entry.  (Ulrich was in
> > the process of changing linuxthreads to keep the thread id in a segment
> > register.  Anyone know if that's making progress?)
>
> The last time I looked at this, there were kernel changes needed to set
> the FS (or was it GS?) segment register per task.  The code in
> linuxthreads can be enabled once the kernel is ready... I have no idea
> if 2.4 will handle this yet.
>
> But other architectures should benefit from hash synchronization as
> well.  Currently, linuxthreads for Alpha uses PAL_rduniq to determine
> the thread ID, which should be significantly faster than examining stack
> registers.

The segment register stuff is in glibc 2.2 and gets enabled if you build glibc
with "--enable-kernel=2.4". When I rolled my own linuxthreads library against a
2.4 kernel, I got a ~15% improvement on a test case with an uncontended lock, and
a small improvment on the PingPong contended lock test. (This is with the regular
locks, not the fastlocks patch). I suspect much of the overhead is in the actual
call to pthread_self().  It looks like we could just pinch the THREAD_SELF macro
from linuxthreads/sysdeps/i386/useldt.h, but it would only work in the presence
of a 2.4 kernel *and* a glibc compiled with kernel 2.4 support enabled. It would
also expose libjava to possible future changes in the linuxthreads internals.

regards

  [ bryce ]