On 6 November 2010 19:49, Stephen Pair <stephen at pairhome.net> wrote:
> 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.
>
No. Its a double-edged sword. If you turn VM into all-safe sandbox,
then you'll have worst performance,
and much less flexibility for developers.
I like David's message: instead of running away from concurrency and
hiding it in secret niches, we should embrace it instead.

> 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
> issue)?
>
I think this is too much to take care of. Different architectures may
have different cache organization
(even different processors could), and so, on one arch your code could
run great, on another arch, it will crawl.

Also, if your parallel algorithm relies on too much shared state, then
it is not good parallel algorithm. You'll never get it working fast
or scale well, no matter how hard you try, because this is same as
trying to fit square into circle.


> Lastly, could you summarize how the design of this VM differs from the
> designs of other multithreaded VMs that have been implemented in the
> past?
>
> Its exciting to see this kind of innovation happening in the squeak community!
>
> -Stephen
>
>



-- 
Best regards,
Igor Stasenko AKA sig.