From: Tony Arcieri Date: 2012-07-08T08:05:51+09:00 Subject: Re: Green threads in 1.9.* ? --0015174c41c8e48d2704c4456bb4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 7, 2012 at 12:57 AM, rex goxman wrote: > Tony Arcieri wrote in post #1067715: > > You're right, there is no debate! Pretty much all major virtual machines > > have moved from green threads to native threads. > > Perhaps it depends on the definition of what is "major." I won't get > into that, everybody has their own definition I guess. But all > Smalltalk VMs I am aware of still use green threads. Smalltalk VM is > state of the art and has been developed for decades, so I don't see how > it couldn't be considered "major." > It's more like Smalltalk VMs used to be state-of-the-art decades ago. Sun hired the Anamorphic team (the creators of Strongtalk) to incorporate their technology into the JVM. They also hired Cliff Click. Cliff Click threw away the Strongtalk JIT compiler and rewrote it from scratch. With the advent of pthreads, which weren't available at the time these Smalltalk VMs you're referencing were written, green threads were ditched for native threads. The result was HotSpot, the JVM we know today, and it's slightly more state-of-the-art than any Smalltalk VM. Azul ran the JVM on systems with 768 cores and heaps of 512GB or more. Erlang processes are entirely "green," in the same way that a green > thread is "green." Yes, nowadays they can be mapped to 'real' threads > running on multiple cores, and that's a good thing. Sorry to get pedantic, but the term "green threads" was termed specifically to distinguish the threading models of systems that don't use native threads from ones which do (i.e. the opposite of "green threaded" is "native threaded"). As soon as you have parallel OS threads (i.e. on a multicore computer) managing the scheduling of multiple userspace threads/"microthreads", you no longer have a "green threaded" system, you have one which is using native threads. These sorts of systems have very different properties from green threaded systems as there is true parallelism. Different threads in the system will have different views of memory at the same time. Erlang used to be green threaded, however with the introduction of the SMP scheduler in R12B Erlang gained native thread/multicore support and Erlang processes began to run in parallel. You are colluding terms and that is what is making the discussion difficult. -- Tony Arcieri --0015174c41c8e48d2704c4456bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 7, 2012 at 12:57 AM, rex goxman <lists@ruby-forum.com> wrote:
Tony Arcieri wrote in post #1067715:
> You're right, there is no debate! Pretty much al= l major virtual machines
> have moved from green threads to native threads.

Perhaps it depends on the definition of what is "major." = =A0I won't get
into that, everybody has their own definition I guess. =A0But all
Smalltalk VMs I am aware of still use green threads. =A0Smalltalk VM is
state of the art and has been developed for decades, so I don't see how=
it couldn't be considered "major."

<= /div>
It's more like Smalltalk VMs used to be state-of-the-art deca= des ago. Sun hired the Anamorphic team (the creators of Strongtalk) to inco= rporate their technology into the JVM. They also hired Cliff Click.

Cliff Click threw away the Strongtalk JIT compiler and = rewrote it from scratch. With the advent of pthreads, which weren't ava= ilable at the time these Smalltalk VMs you're referencing were written,= green threads were ditched for native threads. The result was HotSpot, the= JVM we know today, and it's slightly more state-of-the-art than any Sm= alltalk VM. Azul ran the JVM on systems with 768 cores and heaps of 512GB o= r more.

Erlang processes are entirely= "green," in the same way that a green
thread is "green." =A0Yes, nowadays they can be mapped to 're= al' threads
running on multiple cores, and that's a good thing.
Sorry to get pedantic, but the term "green threads" = was termed specifically to distinguish the threading models of systems that= don't use native threads from ones which do (i.e. the opposite of &quo= t;green threaded" is "native threaded"). As soon as you have= parallel OS threads (i.e. on a multicore computer) managing the scheduling= of multiple userspace threads/"microthreads", you no longer have= a "green threaded" system, you have one which is using native th= reads. These sorts of systems have very different properties from green thr= eaded systems as there is true parallelism. Different threads in the system= will have different views of memory at the same time.

Erlang used to be green threaded, however with the intr= oduction of the SMP scheduler in R12B Erlang gained native thread/multicore= support and Erlang processes began to run in parallel.

You are colluding terms and that is what is making the discussion diff= icult.

--
Tony Arcieri

--0015174c41c8e48d2704c4456bb4--