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 13:45:48 GMT
On 5/23/05, Geir Magnusson Jr. <geirm@apache.org> 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 <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
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> 
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
> 
> 
>

Mime
View raw message