harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: Threading
Date Mon, 23 May 2005 05:05:54 GMT
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 <kumpera@gmail.com> 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 <Steve.Blackburn@anu.edu.au> 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
> >
> 
>

Mime
View raw message