On 5/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On May 23, 2005, at 1:05 AM, Weldon Washburn wrote: > > > 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. > > So how do we examine this today - is there any way to take advantage > of OS threading at all? How do you do thread management now?
I can only speak for how ORP JVM was designed. THe short answer is, yes, the JVM takes advantages of the underlying OS threads. In ORP, I mapped 1:1:1. One java.lang.Thread to one ORP internal thread manager that in turn mappped to one underlying OS thread. This works fine for apps that run only a few threads. It may be a bottleneck for highly threaded apps running on a multicore. > > > 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. > > I've been thinking the same. I was nudged in the direction of > compromise, that realistically, we'll be wanting to use pieces > written in Java. Yes. Exactly. I don't want to see Harmony reinvent the OS for stuff like integrated threading and GC/virt mem mgmt. when we could take advantage of exising code. > > And I'm still going through ANSI C anti-withdrawal. I was looking at > some C code (JamVM?) and the whole thing gave me the shakes. :) > > geir > > > > > > > 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 > >>> > >>> > >> > >> > >> > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
