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
