You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Craig Blake <cr...@mac.com> on 2005/05/22 05:54:51 UTC
Threading
Just out of curiosity, can anyone familiar with the various OSS VM
implementations being discussed share their insights regarding the
respective threading capabilities? I have heard of some commercial
specialty VMs handling upwards of 30,000 concurrent threads easily
and it would be wonderful to be able to have that sort of scalability
(or more!) available in the Harmony effort.
Thanks,
Craig
Re: Threading
Posted by Weldon Washburn <we...@gmail.com>.
On 5/23/05, Geir Magnusson Jr. <ge...@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 <ku...@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 <St...@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
>
>
>
Re: Threading
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 <ku...@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 <St...@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
Re: Threading
Posted by Weldon Washburn <we...@gmail.com>.
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 <ku...@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 <St...@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
> >
>
>
Re: Threading
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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 <St...@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
>
Re: Threading
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 22, 2005, at 2:59 PM, Craig Blake wrote:
>>
>> Seems to me that you might want to be open to either using the
>> platform's threading when a platform has good scalability, and
>> punt and do it in VM when the platform doesn't offer it.
>>
>
> If it can be done then I am all for it. Once the Harmony VM
> becomes modular it is something that can probably be investigated
> further, anyways.
Exactly :)
gier
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Threading
Posted by André Luis Ferreira da Silva Bacci <an...@gmail.com>.
A long, long time ago...
Craig Blake wrote:
>> Seems to me that you might want to be open to either using the
>> platform's threading when a platform has good scalability, and punt
>> and do it in VM when the platform doesn't offer it.
>
> If it can be done then I am all for it. Once the Harmony VM becomes
> modular it is something that can probably be investigated further,
> anyways.
http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg00846.html
until the end of thread.
mainly
http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg00885.html
[]s
André AE
Re: Threading
Posted by Craig Blake <cr...@mac.com>.
>
> Seems to me that you might want to be open to either using the
> platform's threading when a platform has good scalability, and punt
> and do it in VM when the platform doesn't offer it.
If it can be done then I am all for it. Once the Harmony VM becomes
modular it is something that can probably be investigated further,
anyways.
Craig
>
> geir
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Threading
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 22, 2005, at 11:35 AM, Craig Blake wrote:
>> 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.
>>
>
> Whether or not it's worth it depends on your needs. The lack of a
> highly scalable threading model in the current popular VMs is the
> reason why we have to use alternative architectures (like SEDA) to
> make truly scalable servers. Some of us would find it very
> valuable. ;-)
>
> It seems apparent that directly mapping to the underlying thread
> system results in a VM that doesn't scale very well on any of the
> common architectures including both MS and Linux, perhaps a
> different approach would be better?
Seems to me that you might want to be open to either using the
platform's threading when a platform has good scalability, and punt
and do it in VM when the platform doesn't offer it.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Threading
Posted by Craig Blake <cr...@mac.com>.
> 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.
Whether or not it's worth it depends on your needs. The lack of a
highly scalable threading model in the current popular VMs is the
reason why we have to use alternative architectures (like SEDA) to
make truly scalable servers. Some of us would find it very
valuable. ;-)
It seems apparent that directly mapping to the underlying thread
system results in a VM that doesn't scale very well on any of the
common architectures including both MS and Linux, perhaps a different
approach would be better?
Craig
>
> --Steve
>
Re: Threading
Posted by Santiago Gala <sg...@hisitech.com>.
El dom, 22-05-2005 a las 21:09 +1000, Steve Blackburn escribió:
> 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.
A big +1 (and I hope that Goslings eventually read your comment). As a
linux-ppc user I don't feel java is "free enough": I'm restricted to the
ibm-jdk-1.4.2 (not bad, but then, there is no choice), and I don't even
have plugin support for browsers.
One of the things that make OS java inevitable is the trend towards
hardware commoditization. The end of the Wintel monopoly and the rise of
the cellular phones clearly mark this trend, and this trend makes unwise
to depend on a core language or library that you can't port to any
hardware/platform/os.
For me now this is flash (I don't miss it much), java and some voices in
festival. flash is not available at all.
java, the atheros madwifi kernel driver and some festival voices used to
be the only binaries that I had installed. I had to drop the festival
voices as glibc moved. So, just the madwifi driver hal and java
remain...
>
Regards
--
Santiago Gala <sg...@hisitech.com>
High Sierra Technology, SLU
Re: Threading
Posted by Steve Blackburn <St...@anu.edu.au>.
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