2008/7/8 Michael van der Gulik <mikevdg at gmail.com>:
>
>
> If I were working on a concurrent VM, I'd just barge ahead and parallelise
> the Squeak VM:
>
> * I'd refactor the VM so that multiple copies of the interpreter state could
> be held in the heap. I'd design it so that each pthread would run one
> instance of the standard Squeak interpreter, and so that each interpreter
> runs multiple green theads as it does now. This makes forking a very cheap
> operation and allows for having as many green threads as would fit in
> memory.
> * I'd then see what needs fixing in the VM / plug-ins / image to make it
> work. I'd probably start with the simple approach: an evil but simple global
> VM lock for memory writing operations, and no changes to GC. Later, we can
> revisit this to make it scale better.
> * I'd then spend the next decade finding and fixing concurrency bugs.
>

The above is exactly the route on which Hydra VM goes. Btw, in some
near future, i think i'll have strong confidence to declare Hydra on
windoze in beta stage. Stay tuned :)

> What I'm actually going to do is:
>
> * Modify the Squeak schedular to simulate concurrency better and bring up
> lots of concurrency bugs in the image.
> * Spend a decade fixing concurrency bugs in the image.
> * Write enough concurrent code to make it worth having a concurrent VM.
> * Sell that code, make a lot of money.
> * Buy the rights to Gemstone or some other high-performance, concurrent VM.
> * Port my code to that instead.
> * Make a lot more money.
>
Will you buy me an ice cream? :)

> Gulik.
>
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.