[squeak-dev] Re: [Vm-dev] RoarVM: The Manycore SqueakVM
stephen at pairhome.net
Sat Nov 6 17:49:48 UTC 2010
On Wednesday, November 3, 2010, Stefan Marr <squeak at stefan-marr.de> wrote:
> Dear Smalltalk community:
> We are happy to announce, now officially, RoarVM: the first single-image
> manycore virtual machine for Smalltalk.
> The RoarVM supports the parallel execution of Smalltalk programs on x86
> compatible multicore systems and Tilera TILE64-based manycore systems. It is
> tested with standard Squeak 4.1 closure-enabled images, and with a stripped
> down version of a MVC-based Squeak 3.7 image. Support for Pharo 1.2 is
> currently limited to 1 core, but we are working on it.
What great news!
The main question that comes to mind for me is concurrency. Does this
VM do anything special to preserve the concurrency semantics of
smalltalk processes scheduled on a single core? As I'm sure most
people are aware, the existing squeak library isn't written with
thread safety in mind...and as such, even on a single core a naive
implementation can have issues when executing with concurrent
processes. The solution is generally to try and isolate the objects
running in different, concurrent processes and use message passing and
replication as needed. If this VM doesn't do anything in this regard,
I would expect that it would present an even greater risk of issues
stemming from concurrency and it would make it all the more important
to keep objects accessible in different processes cleanly separated.
Another question that comes to mind is how much of a performance hit
you might see from the architecture trying to maintain cache
consistency in the face of multiple processes simultaneously updating
shared memory. Is that something you've found to be an issue? Is
this something you would have to be careful about when crafting code?
And, if it is a problem, is it something where you'd need to be
concerned not just with shared objects, but also with shared pages
(ie. would you need some measure of control over pages being updated
from multiple concurrent processes to effectively deal with this
Lastly, could you summarize how the design of this VM differs from the
designs of other multithreaded VMs that have been implemented in the
Its exciting to see this kind of innovation happening in the squeak community!
More information about the Squeak-dev