performance problems

[Jeff Sturm]

Tom Tromey wrote:
> The current thread code in libgcj was designed for simplicity.  I have
> never done any profiling to see how fast or slow it might be.  We can
> change it, even on a per-OS basis (e.g., a Linux-specific
> implementation), if that would help a lot.

(oops... missed this statement first time through.)

I'm not sure what we would do... the pthreads API is mostly adequate, so
if we find anything broken, I feel we're better off fixing LinuxThreads
than creating a workaround.  We could bring in our own spinlock code (as
the Boehm GC has done) but that'd just become more work in porting and
maintenance.

One potential problem with LinuxThreads is the 1-1 mapping of
application threads to kernel tasks.  Under that model, henever
applications have more runnable threads than available processors, they
begin to thrash.  Other OSes like Solaris and Tru64 Unix solve this
problem with a hybrid model of kernel and cooperative threads.  That's a
nice solution, but very difficult to implement correctly... and the
LinuxThreads page seems to say they prefer simplicity.

If someone really wanted to experiment with a mixed thread model, they
could try it in libgcj.  It would be a huge task though.

--
Jeff Sturm
jsturm@sigma6.com