Ian Rogers wrote:
Archie Cobbs wrote:
IMHO using POSIX threads is the only "right" answer for a multi-platform
JVM. You have no other choice except to leave it up to the specific
platform to then implement POSIX threads efficiently.
For example, on Linux where each POSIX thread is a cloned process, it's
Linux's fault (not the JVM's fault) if that doesn't scale well. For
example,
other OS's don't have such heavyweight threads. FreeBSD's KSE's are an
example of a better tradeoff using M:N user:kernel threading.
I agree with you. I think it's always the case that Java threads are
going to be better than POSIX threads though, as with some commodity
processors, in particular I'm thinking of Cell, you no longer have a
shared memory model. In such a situation you could use a distributed
JVM, such as JESSICA2 - that's built on top of Kaffe :-). So whilst
implementing a JVM assuming POSIX threads is a good idea to run on many
platforms, there are legitimate reasons why you may want to be flexible
and not assume a 1-to-1 mapping of Java threads to POSIX threads, and of
course avoid native code.
You're right.. there is a subtlety here I was glossing over.
When referring to "threads" above, I guess I meant things that actually
need to consume C runtime stack. For example, if you have code that
invokes read(2), this code needs to have it's own C runtime stack and
needs a "real" O/S-supplied thread to sleep with. Any time you invoke
JNI native code, you'll also need a "real" thread and runtime stack.
On the other hand, Java threads are entirely virtual and their stacks
don't have to correspond 1:1 to C runtime stacks (although it surely
is convenient to do it that way). I don't know which JVMs make this
distinction. You would have to "lend" a real thread to a Java thread
anytime it invokes native code. But you could re-use that thread once
the thread returned to Java code; if the thread called back into Java
code from within the native method, you could also return the real thread
to the thread pool, but the chunk of C runtime stack that supported the
native method call would have to be saved somewhere of course. You'd
need a lot of longjmp() or setcontext() magic to do this.
The upshot would be that you only use "real" threads when absolutely
required, e.g., you're making a blocking system call, and Java threads
would be very lightweight (corresponding merely to linked lists of
Java stack frame structures, or whatever).
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
