Searching with the right keywords should have directed you to HydraVM[1]
and RoarVM[2][3], which are two different approaches to this problem.
Both projects are stalled, and would require significant effort to merge
them with the current VM sources.
RoarVM also requires images changes, because it brings the concurrency
problems up to the Smalltalk level.
There are plans for Spur to have some kind of support for multi-core
machines, though that'll be different than what you described, because
Smalltalk code will still be executed by one core at a time.
Levente
[1]
http://forum.world.st/ANN-Hydra-VM-A-multi-core-capable-Croquet-VM-td106298.html
[2] http://stefan-marr.de/2010/11/roarvm-the-manycore-squeakvm/
[3] https://github.com/smarr/RoarVM
On Wed, 18 Nov 2015, EuanM wrote:
(And yes, I know it's actually here already).
Now that clock-speed rises have stalled, basically forever, desktop
and laptop PCs are growing ever-increasing numbers of cores in their
CPU chips,
Is there design and conceptualisations work going on to see how Pharo
will deal with providing increased access to the additional processing
power?
One thing I have been thinking about is a set of co-operating Pharo VMs.
But given memory and storage are shared, this may not provide as large
a benefit as we'd like.
Or moving Pharo into being having multiple native-threads, and taking
Pharo into a concurrency route.
Or - whatever it is I am too ignorant to see.
This all strikes me (like the way Smalltalk is extending its system
boundary out onto the web with Monticello, Pharo is extending that
via the Configuration Browser and Versionner) as a way Pharo could
build on Smalltalk, while becoming its own thing. (as opposed to
being a Smalltalk with a very big set of classes).
Is there thought work going on in this area yet?
DabbleDB had a system of running multiple VMs on a server, and
hot-swapping them in and out depending on their CPU loading.
Did that ever get developed intop a more generally-useful facility?
