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?
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.
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]
