harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Threading
Date Mon, 23 May 2005 12:07:17 GMT

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. :)


> 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

View raw message