Re: Green threads - some experience
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. It seems you are some years behind actual development. The threading model you describe was used till linux-2.4, since 2.6 NPTL is used instead which outperforms almost everything else. lg Clemens
Re: Green threads - some experience
Clemens Eisserer wrote: 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. It seems you are some years behind actual development. The threading model you describe was used till linux-2.4, since 2.6 NPTL is used instead which outperforms almost everything else. Good to hear that :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
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. Regards, Ian
Re: Green threads - some experience
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
Re: Green threads - some experience
Ian Rogers wrote: The AWT peer problems were caused primarily by pthread mechanisms being used by GTK. These are wrapped in a library called gthreads. A Java thread would: 1) enter some native code that acquired a pthread mutex 2) call back into the JVM 3) the JVM would switch Java thread 4) the Java thread would call code that required the original mutex and block in native code not allowing other threads to get scheduled Hi, why didn't you modify GTK instead? Calling back into the JVM (with unpredictable consequences) whilst holding a pthread mutex is a bad idea. Cheers, Dave
Re: Green threads - some experience
Ian Rogers writes: I think the long term view is to switch to POSIX threads. Having used the Jikes RVM for an OS like project, relying on native threads wouldn't have been desirable. In theory green thread context switches should be possible in a few instructions whereas a full context switch takes a few hundred. I guess its all down to the situation the JVM is trying to optimise for. Indeed. I've been thinking about this, and it occurs to me that threads are used to solve two entirely problems, and which threading model is desirable depends on which problem you are trying to solve. 1: How do I organize my program in such a way that it is easy to write/maintain/understand and runs fast on commodity hardware? 2: I can put a quarter of a billion transistors on a piece of silicon 200 square millimetres in size. How can I write my program in such a way that it uses all those transistors to best effect? I suspect that the answer to 1 is (or was) to have lightweight user-space threads and the answer to 2 is to use a (perhaps smaller) number of kernel threads. In particular, the issue of process affinity may be so important to solving Problem 2 that green threads aren't an answer. Also, if all but one of my processors are idling, a super-light context switch isn't any compensation. I believe that the general trend in commodity desktop hardware is towards multi-core / multi-thread processors, where good performance depends on the kernel's ability to manage processor allocation between threads. Because of this, green threads are a dead end. Of course, in real life there are many shades of grey between these two problems. But it does explain why in our exchanges we were so often talking at cross purposes: we were trying to solve different problems. Andrew.
Re: Green threads - some experience
Andrew Haley wrote: I think the long term view is to switch to POSIX threads. Having used the Jikes RVM for an OS like project, relying on native threads wouldn't have been desirable. In theory green thread context switches should be possible in a few instructions whereas a full context switch takes a few hundred. I guess its all down to the situation the JVM is trying to optimise for. Indeed. I've been thinking about this, and it occurs to me that threads are used to solve two entirely problems, and which threading model is desirable depends on which problem you are trying to solve. 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. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Ian == Ian Rogers [EMAIL PROTECTED] writes: Ian I'd just like to describe my experiences of getting m-to-n threading Ian going with classpath gtk peers and the Jikes RVM. It could possibly be Ian instructive for developers and/or other JVMs. Thanks for writing this. What do you think of putting it on the wiki or in the classpath vm integration guide? Maybe we could have a section on advice to VM implementors. Tom
Green threads - some experience
Hi, I'd just like to describe my experiences of getting m-to-n threading going with classpath gtk peers and the Jikes RVM. It could possibly be instructive for developers and/or other JVMs. There are different models of threading: 1) native threads: map Java threads to native pthreads - talking to people suggests this is the preferred method by classpath developers and is in the widest use 2) green threads 1: run Java threads as a single thread then on timer switch the running thread. This method is used by Kaffe's jthreads. 3) green threads 2: run Java threads as a single thread, on a timer interrupt set a flag indicating a yield is desired. At points in the code test this flag and yield if necessary. 4) m-to-n: run m green Java threads on n native threads. This approach is adopted in the Jikes RVM with green threads 2. The biggest problem is: Java threads can call into native code. This native code can call out to Java code. Not all native code will return to Java code or call out to Java code (e.g. gtk_main). If your JVM uses the green threads 2 model this presents a problem scheduling other threads. The Jikes RVM solves this problem by having a back up thread that non-blocked Java threads can be switched onto. The original Java thread continues to be blocked on the native thread. However, if the back up thread becomes blocked there's a problem. To reduce and optimise this problem the Jikes RVM replaces some system calls with non-blocking alternatives. The AWT peer problems were caused primarily by pthread mechanisms being used by GTK. These are wrapped in a library called gthreads. A Java thread would: 1) enter some native code that acquired a pthread mutex 2) call back into the JVM 3) the JVM would switch Java thread 4) the Java thread would call code that required the original mutex and block in native code not allowing other threads to get scheduled To solve this there is the portable native sync option with classpath. This option swaps the gthread mechanisms with ones that call back into the JVM. Unfortunately it is broken, will only work for GTK code and won't work if there is already GTK code using the gthread library (for example, if the JVM is a plugin). Another option is to modify classpath so that at the points where mutexs are acquired, if a mutex is busy then call back into the JVM. However, this option isn't desirable as its not required for a lot of JVMs. Another option is to try to stop the Java threads entering native code if on that native thread a Java thread is already in native code. This proved to be buggy and slow, it is likely the scheduler needs work with this option. So the simplest solution[1] was to hijack the pthread mutex locking and waiting calls and replace them with versions that call back into the JVM. This works well but the final implementation isn't quite bug free. [1] changing the threading model to using native threads wasn't considered simple. The current Jikes RVM CVS head is using this mechanism and is no longer using portable native sync. It is very likely that this code is now redundant. The JNI spec. and programmers guide section 8.1.5: http://java.sun.com/docs/books/jni/html/other.html#29406 describes consulting JVM documentation before embarking on threaded native code. Regards, Ian Rogers --- http://www.cs.man.ac.uk/~irogers/
Re: Green threads - some experience
Intersting post Ian. Maybe I'm linux 2.6 biased... but wouldn't simply using POSIX threads be so much better? NPTL is so nice. Nic
Re: Green threads - some experience
Hi Nic, I think the long term view is to switch to POSIX threads. Having used the Jikes RVM for an OS like project, relying on native threads wouldn't have been desirable. In theory green thread context switches should be possible in a few instructions whereas a full context switch takes a few hundred. I guess its all down to the situation the JVM is trying to optimise for. Microsoft's Singularity OS makes an advantage out of not requiring full context switches. If you have as many hardware contexts as threads, then green threads would be an unnecessary overhead. Ian Nic wrote: Intersting post Ian. Maybe I'm linux 2.6 biased... but wouldn't simply using POSIX threads be so much better? NPTL is so nice. Nic
