Interestingly Sun Solaris 9 dropped M:N threads. From http://www.sun.com/software/whitepapers/solaris9/multithread.pdf, "One such innovation is the move away from the original MxN model to a 1:1 implementation". "Again, this is not to say that a good implementation of the MxN model is impossible, but simply that a good 1:1 implementation is probably sufficient."
Long term, I suspect that the thread management code that sits inside today's JVM and the thread scheduler that sits inside today's standard OS will merge. Generic LinWin preemptive thread scheduling that suspends a thread at an arbitrary location is not compatible with the GC's need to have threads suspended at GC safepoints. While this may not be a big deal on today's 1-4 way CPU systems, its likely to become a bottleneck on tomorrow's multicore boxes. Most likely the merged/unified thread scheduler will be written in a type-safe language such as Java. The interesting long term question is when will the entire JVM be merge into the underlying OS? And when will the resultant JVM/OS be re-written in a type-safe language? I suspect a modular Harmony that allows a mix and match of components in ansi C (popular with the OS crowd) and components written in Java/C# will be very useful. On 5/22/05, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote: > Green threads have a lot of problems that are hard to solve. You have to > deal with blocking function, interupts, syscall restarts, blocking native > code, etc... > > JikesRVM handles that gracefully? My impression is that everyone is dropping > this M:N model because of implementation issues. BEA dropped it on jrockit. > IBM was developing such system for posix threads in linux, but a simple 1:1 > that solved some scalability problems in the kernel was choosen. > > > > > > On 5/22/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: > > > > The Jikes RVM experience is kind of interesting... > > > > From the outset, one of the key goals of the project was to achieve > > much greater levels of scalability than the commercial VMs could deliver > > (BTW, the project was then known as Jalapeno). The design decision > > was to use a multiplexed threading model, where the VM scheduled its own > > "green" threads on top of posix threads, and multiple posix threads were > > supported. One view of this was that it was pointless to have more than > > one posix thread per physical CPU (since multiple posix threads would > > only have to time slice anyway). Under that world view, the JVM might > > be run on a 64-way SMP with 64 kernel threads onto which the user > > threads were mapped. This resulted in a highly scalable system: one of > > the first big achievements of the project (many years ago now) was > > enormously better scalability than the commercial VMs on very large SMP > > boxes. > > > > I was discussing this recently and the view was put that really this > > level of scalability was probably not worth the various sacrifices > > associated with the approach (our load balancing leaves something to be > > desired, for example). So as far as I know, most VMs these days just > > rely on posix style threads. Of course in that case your scalability > > will largely depend on your underlying kernel threads implementation. > > > > As a side note, I am working on a project with MITRE right now where > > we're implementing coroutine support in Jikes RVM so we can support > > massive numbers of coroutines (they're using this to run large scale > > scale simulations). We've got the system pretty much working and can > > support > 100000 of these very light weight threads. This has been > > demoed at MITRE and far outscales the commercial VMs. We achieve it > > with a simple variation of cactus stacks. We expect that once > > completed, the MITRE work will be contributed back to Jikes RVM. > > > > Incidentally, this is a good example of where James Gosling misses the > > point a little: MITRE got involved in Jikes RVM not because it is > > "better" than the Sun VM, but because it was OSS which meant they could > > fix a limitation (and redistribute the fix) that they observed in the > > commercial and non-commercial VMs alike. > > > > --Steve > > > >
