Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hydra VM is codename, which we have choose to call this project :)
Currently, i had refactored enough code in Interpreter/Plugins and win32 platform-specific code to be able to load and run multiple images in same process.
There is much to be done left, but i think, at the moment, there is enough support in VM to write tests and experiment, without much risk of crashes. If you run single image, and don't start second or more, it's stable! (i'm sitting in VM, editing code during the day, saving image e.t.c. - about 8 hours or so, and no crashes ). Of course, expect crashes, when you run new image. :) But there is nuances: since i'm too lazy to look for a stripped down image with limited number of facilities, i'm using stock image to run in second thread. Of course, this is very risky , because it's trying to use everything (display/input) and this leads to crash. So, currently, to prevent that, i changed snapshot:andQuit:embedded: method to simply don't go past tests, which are running at starting image (there is a ways to detect if you running as main interpreter or not).
I'm going to make further changes to ensure, that VM will not crash, even when trying to run stock images which may think that they are interactive. Meanwhile, to one, who might have interest, you can download and start playing with it. Sorry, it's currently running on win32 platform only. If there any interest in porting to other platforms i would glad to help.
Lately, i have done implementing channels , a framework for fast and cheap inter-image communication. If you load a HydraVM package, there is already some code, which using them:
#transcript channel, used by HydraTranscript class , as a simple way to see what other image doing, by redirecting all transcript output to main, interactive, image.
#doIt channel - a channel, which listen non-interactive image, where you can send doits.
You can download VMMaker and HydraVM from here: MCHttpRepository location: 'http://jabberwocky.croquetproject.org:8889/HydraVM' user: '' password: ''
And platform source code, for building it, from here: http://squeakvm.org/svn/squeak/branches/qwaq
Any questions? ask away!
On Mon, Dec 24, 2007 at 11:24:47PM +0200, Igor Stasenko wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hydra VM is codename, which we have choose to call this project :)
This sounds very interesting indeed. What a nice follow up to all the earlier discussions on this topic, a real implementation! Well done.
Excellent name too.
Dave
On 25/12/2007, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Dec 24, 2007 at 11:24:47PM +0200, Igor Stasenko wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hydra VM is codename, which we have choose to call this project :)
This sounds very interesting indeed. What a nice follow up to all the earlier discussions on this topic, a real implementation! Well done.
There is more and more pressing matters, because we are standing at rising multi-core era. So, we need tools for fully utilizing their powers.
Excellent name too.
Dave
If someone could email me (not the list) their src32 VMMaker results for Hydra that would be appreciated.
On Dec 25, 2007, at 8:26 AM, stephane ducasse wrote:
There is more and more pressing matters, because we are standing at rising multi-core era. So, we need tools for fully utilizing their powers.
yes! So what would be a typical set up of multiple images from your perspective?
Stef
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On 25/12/2007, stephane ducasse stephane.ducasse@free.fr wrote:
There is more and more pressing matters, because we are standing at rising multi-core era. So, we need tools for fully utilizing their powers.
yes! So what would be a typical set up of multiple images from your perspective?
There can be a wide range of deployment models, depending on intents. As i said, its a general purpose VM, and therefore things you can do with it depends on your imagination :)
For Seasiders, there now a good perspectives to have a single 'main' image, which accepts incoming connections, and do load-balancing between smaller images which do all dirty work. You could have much finer control on things comparing to running multiple squeak processes.
I think, that Andreas having own ideas how to use new VM, and i think it's better ask him to describe where it will be used.
But things are more or less the same: distribute the tasks between multiple images, making them performing in parallel.
2007/12/26, Igor Stasenko siguctua@gmail.com:
On 25/12/2007, stephane ducasse stephane.ducasse@free.fr wrote:
There is more and more pressing matters, because we are standing at rising multi-core era. So, we need tools for fully utilizing their powers.
yes! So what would be a typical set up of multiple images from your perspective?
There can be a wide range of deployment models, depending on intents. As i said, its a general purpose VM, and therefore things you can do with it depends on your imagination :)
For Seasiders, there now a good perspectives to have a single 'main' image, which accepts incoming connections, and do load-balancing between smaller images which do all dirty work.
How would that work? How would you pass a request to a different image? How would it return the response? How would you keep the images in sync (deploy code to all the images)? I still feel that for Seaside one Image with multiple native threads would be the best option.
Cheers Philippe
You could have much finer control on things comparing to running multiple squeak processes.
I think, that Andreas having own ideas how to use new VM, and i think it's better ask him to describe where it will be used.
But things are more or less the same: distribute the tasks between multiple images, making them performing in parallel.
-- Best regards, Igor Stasenko AKA sig.
On 26/12/2007, Philippe Marschall philippe.marschall@gmail.com wrote:
For Seasiders, there now a good perspectives to have a single 'main' image, which accepts incoming connections, and do load-balancing between smaller images which do all dirty work.
How would that work? How would you pass a request to a different image? How would it return the response? How would you keep the images in sync (deploy code to all the images)?
See, Hydra VM is just VM it's not a smallatlk application (such as Seaside). And of course, to resolve all of the above there a lot to do and think of.
I still feel that for Seaside one Image with multiple native threads would be the best option.
If you talking about making single image be able to run using multiple native threads.. oh.. There was a lot of discussions around that. And i think, that my attempt to introduce multithreading into VM at least on a per-image basis is a step forward to it.
Igor Stasenko ha scritto:
On 26/12/2007, Philippe Marschall philippe.marschall@gmail.com wrote:
For Seasiders, there now a good perspectives to have a single 'main' image, which accepts incoming connections, and do load-balancing between smaller images which do all dirty work.
How would that work? How would you pass a request to a different image? How would it return the response? How would you keep the images in sync (deploy code to all the images)?
See, Hydra VM is just VM it's not a smallatlk application (such as Seaside). And of course, to resolve all of the above there a lot to do and think of.
Two possible solutions:
- have a common protocol for Channel and Socket operations, so that Kom may listen either on the former or on the latter without changing any code.
- use a Kom variant that knows it's a "slave" process in one of the load balanced images. In this case, it could use channels to receive HttpRequest objects from and return HttpResponse objects to the load balancing image.
Giovanni
PS. Great work, Igor (and Andreas, too)!
On 26/12/2007, Giovanni Corriga giovanni@corriga.net wrote:
Igor Stasenko ha scritto:
On 26/12/2007, Philippe Marschall philippe.marschall@gmail.com wrote:
For Seasiders, there now a good perspectives to have a single 'main' image, which accepts incoming connections, and do load-balancing between smaller images which do all dirty work.
How would that work? How would you pass a request to a different image? How would it return the response? How would you keep the images in sync (deploy code to all the images)?
See, Hydra VM is just VM it's not a smallatlk application (such as Seaside). And of course, to resolve all of the above there a lot to do and think of.
Two possible solutions:
- have a common protocol for Channel and Socket operations, so that Kom
may listen either on the former or on the latter without changing any code.
- use a Kom variant that knows it's a "slave" process in one of the load
balanced images. In this case, it could use channels to receive HttpRequest objects from and return HttpResponse objects to the load balancing image.
I think, the latter is more appropriate, because channels don't have 'listen/accept' semantics. Once channel is created, it starts listening for incoming data, not connections. But this can be easily changed by introducing a framework on top of that. For instance, you can create a channel which will listen for 'connections', and then upon request, it creates new channel and sending it's name/id in response which will be used to receive incoming data.
GiovanniPS. Great work, Igor (and Andreas, too)!
On Dec 25, 2007 10:24 AM, Igor Stasenko siguctua@gmail.com wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hi Igor.
Good work! However, why are you doing this? Why is this better than running multiple Squeak images on the same machine with different VMs? I'm not understanding what the advantage is over forking off several VMs in the usual way and using some fast inter-process communication between them (such as shared memory, pipes or TCP/IP).
Gulik.
On 25/12/2007, Michael van der Gulik mikevdg@gmail.com wrote:
On Dec 25, 2007 10:24 AM, Igor Stasenko siguctua@gmail.com wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hi Igor.
Good work! However, why are you doing this? Why is this better than running multiple Squeak images on the same machine with different VMs? I'm not understanding what the advantage is over forking off several VMs in the usual way and using some fast inter-process communication between them (such as shared memory, pipes or TCP/IP).
Good question. Communication within same process can be as fast as reading memory. And, of course without being too dependent from OS (shared memory, pipes or TCP/IP). Another is, that it's certainly much simpler to manage multiple images within single process boundaries than manage multiple OS processes. Next reason, that some external resources can require an exclusive access , and writing plugin which can manage it for multiple images in single OS process is much easier than writing a plugin which try manage access for multiple OS processes.
So, in short: main difference is, that multiple OS processes share nothing and can communicate only using provided OS facilities. In Hydra VM you still sharing nothing between images, but different VM/plugins/OS states are now shareable.
Hi Igor,
on Mon, 24 Dec 2007 22:24:47 +0100, you wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hydra VM is codename, which we have choose to call this project :)
Wow, what a project, what a name :-D
There is much to be done left, but i think, at the moment, there is enough support in VM to write tests and experiment, without much risk of crashes.
...
Any questions? ask away!
How about passing a socket's handle to one of the serpent's heads. See (aSocket socketHandle) in #acceptFrom: of Socket.
That looks easy doable, (aSocket socketHandle) could be passed as a constant bytearray, similiar to sending something to the #transcript or #doIt channel, and the result of #acceptFrom: is totally controlled on the serpent head's side.
Can you see any problem with this, OS-wise or other? If not I could give it a try.
/Klaus
On 25/12/2007, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Hi Igor,
on Mon, 24 Dec 2007 22:24:47 +0100, you wrote:
Hello everyone, i would like to make anyone know, what i have done during December in a collaboration with Andreas, for creating a VM, which can run multiple squeak images in separate native threads, running in parallel.
Hydra VM is codename, which we have choose to call this project :)
Wow, what a project, what a name :-D
There is much to be done left, but i think, at the moment, there is enough support in VM to write tests and experiment, without much risk of crashes.
...
Any questions? ask away!
How about passing a socket's handle to one of the serpent's heads. See (aSocket socketHandle) in #acceptFrom: of Socket.
That looks easy doable, (aSocket socketHandle) could be passed as a constant bytearray, similiar to sending something to the #transcript or #doIt channel, and the result of #acceptFrom: is totally controlled on the serpent head's side.
Can you see any problem with this, OS-wise or other? If not I could give it a try.
Sockets are managed by socket plugin and keep own, private separate list for each interpreter instance. You may pass it, but if you try use it with other interpreter, which creates it, all primitives will fail. This can be changed however, i see good reasons why socket handles can be passed between images.
/Klaus
On 25/12/2007, Igor Stasenko siguctua@gmail.com wrote:
Sockets are managed by socket plugin and keep own, private separate list for each interpreter instance. You may pass it, but if you try use it with other interpreter, which creates it, all primitives will fail. This can be changed however, i see good reasons why socket handles can be passed between images.
On second thought, i say no. There is many concurrency issues arising, when two (or more) independent interpreters trying to work with same socket handle. Of course OS sockets are thread safe, but structures, assigned to them for serving ST side, like semaphores, mutexes and different state vars are unique and should be accessed synchronously.
However, its very easy to write few additional primitives which tell socket to redirect all incoming data to specified channel, and also make socket to behave like a channel which listens for data.
Since sockets (at least in windows) using own thread, there is no real difference, where to pass data - in channel or to some buffer. And speed degradation should be minimal (if it will be at all).
Also, erasing differences between channels and sockets having many benefits - common interface, simple use. Currently channel features is not very mature, and i'm already don't like some of their current functionality. I thought it was a good idea to have named channels. It's much more convenient for developer to use names instead of port numbers to identify them. But channel discovery mechanism needs more thought. well, this is only preliminary design and use cases will show us what need to be changed.
There are already some variants, which i would like to see for channels: like using staticaly allocated buffer queue, so writing to channel will not require memory allocation for buffer and freeing it upon receipt. Also, its possible to pull data from channel in 'hot' manner - without waiting semaphore. So, for heavy data throughput tasks or for a fast, realtime reacting on events, you can create at process which will constantly pulling data from channel without waiting on semaphore.
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Giovanni Corriga -
Igor Stasenko -
John M McIntosh -
Klaus D. Witzel -
Michael van der Gulik -
Philippe Marschall -
stephane ducasse