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.
