Indeed, it looks as though things have moved on--on Linux at least--from my last experience of using Java.
About Linux Threads
One major difference between developing on Linux from other Unix operating systems is the system threads library. In Java 2 releases prior to 1.3, the Java virtual machine uses its own threads library, known as green threads, to implement threads in the Java platform. The advantage here is that green threads minimize the Java virtual machine's exposure to differences in the Linux threads library and makes the port easier to complete. The downside is that using green threads means system threads on Linux are not taken advantage of and so the Java virtual machine is not scalable when additional CPUs are added.
In Java 2 Release 1.3, the Hotspot virtual machine uses system threads to implement Java threads. Because Linux threads are implemented as a cloned process, each Java thread shows up in the process table if you run the ps command. This is normal behavior on Linux.
In the above listing, the process ID 11712 shown in the left-most PID column is the invoked Java virtual machine. The other processes that show process ID 11712 in the PPID column have process ID 11712 as their parent process. These children to process ID 11712 are Java threads implemented by the Linux system threads library. Each Linux thread is created as a process clone operation, which leaves the scheduling of threads to be a task of the process scheduler.
By comparison, on Solaris the Java threads are mapped onto user threads, which in turn are run on Lightweight processes (LWP). On Windows the threads are created inside the process itself. For this reason, creating a large number of Java threads on Solaris and Windows today is faster than on Linux. This means you might need to adjust programs that rely on platform-specific timing to take a little longer on startup when they run on Linux.
I'd question your conclusion regarding the efficiency of pthreads, but as I do not have any great experience of them I can only base my judgements upon generic information. Having user threads map 1:1 to kernel threads seems like an ideal situation, but history shows that it has nearly as many drawbacks as advantages.
Update: More generic information:
Linux Thread Optimizations
The first thing Java developers notice when running their application on Linux is that the ps command, used to display the list of processes, appears to show multiple copies of Java runtime environment running even though only one Java application was started.
This is due to the implementation of the system threads library on Linux. Linux threads are implemented as a cloned process, that means each Java thread appears as a new Linux process. The advantage of this approach is that the threads implementation is simpler and stable, however the downside is that this also affects the performance of even a moderately threaded Java application on Linux.
Update2: And yet another demonstration that one to one user/kernel thread mapping is invariably bad for performance.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.