On 10/27/07, Rob Withers reefedjib@yahoo.com wrote:
----- Original Message ----- From: "Peter William Lount" peter@smalltalk.org
You're plan sounds excellent. Thank you for taking up the task of making Squeak VM multi-threaded with native threads!
If you need anything...
I don't want to make it sound like I can't use some help, especially if it's offered. I can't do this alone. Forget it, especially with the day job. No, I figure it to be a 2 year task, at least. But I would rather build something than talk about all the theory. I fleshed out the phases I posted earlier with what I thought were some more managable tasks. I'd like to point out that Phase 3, implementing the multithreaded vm, is entirely independent of SqueakElib and would be useable by anyone wanting to do multithreading.
Here's the new page, add what you like, help where you can, holler to talk it over: http://wiki.squeak.org/squeak/6011
Hi Rob.
I think that many other people would be interested in this. I suggest making stage 3 here a separate project in its own right. If it is stable and works well, I could see it becoming the official Squeak VM. Also keep integration with Exupery in mind.
I also recommend starting this project by changing the behaviour of ProcessorScheduler to behave in the same way as the multi-threaded VM. Currently code can assume that a lower priority process won't run while a higher priority process is busy; this assumption would no longer exist in the multi-threaded VM. This would be a reasonably simple change and I believe this may pick up several concurrency issues in the image.
Gulik.
Hey Gulik,
I think that's a great idea. I moved the appropriate section to a new wiki page. http://wiki.squeak.org/squeak/6012
Cheers, Rob
----- Original Message ----- From: Michael van der Gulik
I think that many other people would be interested in this. I suggest making stage 3 here a separate project in its own right. If it is stable and works well, I could see it becoming the official Squeak VM. Also keep integration with Exupery in mind.
I also recommend starting this project by changing the behaviour of ProcessorScheduler to behave in the same way as the multi-threaded VM. Currently code can assume that a lower priority process won't run while a higher priority process is busy; this assumption would no longer exist in the multi-threaded VM. This would be a reasonably simple change and I believe this may pick up several concurrency issues in the image.
Hi Rob, all,
a concrete initiative after so much discussion. I'm happy to hear that. I think being conservative like the N interpreters model is a good desicion at this, not so mature in multicore-stage. It buys time for more long run ones.
All the best for the teams!
Sebastian Sastre
_____
De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Rob Withers Enviado el: Viernes, 26 de Octubre de 2007 22:29 Para: The general-purpose Squeak developers list Asunto: Re: Multi-threaded VM
Hey Gulik,
I think that's a great idea. I moved the appropriate section to a new wiki page. http://wiki.squeak.org/squeak/6012
Cheers, Rob
----- Original Message ----- From: Michael van der mailto:mikevdg@gmail.com Gulik
I think that many other people would be interested in this. I suggest making stage 3 here a separate project in its own right. If it is stable and works well, I could see it becoming the official Squeak VM. Also keep integration with Exupery in mind.
I also recommend starting this project by changing the behaviour of ProcessorScheduler to behave in the same way as the multi-threaded VM. Currently code can assume that a lower priority process won't run while a higher priority process is busy; this assumption would no longer exist in the multi-threaded VM. This would be a reasonably simple change and I believe this may pick up several concurrency issues in the image.
Michael van der Gulik writes:
Hi Rob.
I think that many other people would be interested in this. I suggest making stage 3 here a separate project in its own right. If it is stable and works well, I could see it becoming the official Squeak VM. Also keep integration with Exupery in mind.
So long as there are no object memory changes then Exupery should be easy to port to it. The only thing to be aware of is Context objects that are being executed are not accurately populated. This is not a problem for a single threaded VM as it's impossible to reflect on a context without exiting it to execute the primitive.
That said, I don't think it would be that hard to make the VM multi threaded. It would probably require a GC rewrite but such a rewrite could also make single threaded execution faster and allow for a mostly background old space collector. I've thought about such a rewrite when looking at some memory access sequences but it would be after Exupery 3.0 in my list. Squeak's GC is a good fit for the current interpreter but may start looking slow if execution was 10 times faster.
Bryce
squeak-dev@lists.squeakfoundation.org
-
bryce＠kampjes.demon.co.uk -
Michael van der Gulik -
Rob Withers -
Sebastian Sastre