Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of kumpera@gmail.com designates
 64.233.170.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
        b=DcREbIqiTGvTwWH/Pl7O6lx78ZtdMz+dIRYbEmnlrPULtr9BJYQV+WY3abzUnD9mO9suXJpLDL68jbqG/s/S6q/RTUNveDhRziW45X1zTA2UuuGtpb4LD3nfvYYrHrx0a81qRZjqs4KAUlPDYa8VGAZSLdW/dJFuPnrC5KcMIzU=
Message-ID: <8cca42d805052208524dbb6780@mail.gmail.com>
Date: Sun, 22 May 2005 12:52:25 -0300
From: Rodrigo Kumpera <kumpera@gmail.com>
Reply-To: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Threading
In-Reply-To: <42906860.9000004@anu.edu.au>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2621_19146721.1116777145957"
References: <D081B6DF-3564-4343-8E43-BB3AE6F9656D@mac.com>
	 <42906860.9000004@anu.edu.au>

------=_Part_2621_19146721.1116777145957
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Green threads have a lot of problems that are hard to solve. You have to=20
deal with blocking function, interupts, syscall restarts, blocking native=
=20
code, etc...

JikesRVM handles that gracefully? My impression is that everyone is droppin=
g=20
this M:N model because of implementation issues. BEA dropped it on jrockit.=
=20
IBM was developing such system for posix threads in linux, but a simple 1:1=
=20
that solved some scalability problems in the kernel was choosen.


On 5/22/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
>=20
> The Jikes RVM experience is kind of interesting...
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> --Steve
>

------=_Part_2621_19146721.1116777145957--