[squeak-dev] Proposal for CroquetMT [was: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!]

Klaus D. Witzel klaus.witzel at cobss.com
Tue Jul 8 08:51:51 UTC 2008


On Mon, 07 Jul 2008 10:08:54 +0200, Andreas Raab wrote:

...
> It's not about preventing anything. If you have a proposal for how to do  
> multiple threads per image I will most definitely listen,

Yesterday I've pulled together things (from old and also from more recent  
drawers) that can make a CroquetMT (MT suffix came from Igor) and sent  
that material for overnight review to Igor (many thanks to Igor; hope he  
didn't get distracted from more important projects ;) Of course I had to  
defend one and another point but the picture remained clear. What came out  
is this (high level):

o MT without locking objects, without per-object owner slot
o each native thread has own heap (own ObjectMemory like Hydra)
o an MT thread is responsible for messages sent to "its" objects
o the main .image has also its MT thread
o all other MT threads start with empty image
o object allocation is always local, no migration needed
o instance creation is easy but too many details for a short post
o storing oops cross MT thread is easy but too many details for a short  
post
o same for global vars, easy but also too many details for a short post
o GC is local for non-main .images but special for the main .image
o no change in existing Smalltalk code necessary, just use it

FWIW, parts of the concepts stem from the Goya project (Squeak, coloring  
of instances) with Alex Bergel.

The main principle, which I based on Igor's "islands for CorruptVM"  
suggestion (island term can be confusing to people when used with this new  
MT stuff, must find alternate word), is this:

- sending a message to a receiver which is not in the current MT thread's  
"island" causes the message to be scheduled for execution in the other MT  
thread.
- this is independent of the receiver's memory location, "island" is  
something else.
- can be thought of like a FutureRef on which the current process  
immediately waits.
- so as long as receivers are in the same "island" no MT-scheduling  
happens.
- I know this may sound similiar to many other concepts but, hey, we are  
not there yet.

> and if it is a reasonable proposal (i.e., one that can be implemented  
> with bounded resources) I will even try to find funding for it.

I would very much like to get a bounty for a thing like CroquetMT but  
unfortunately I'm partly disabled (double crunch surgery) so I cannot be a  
reliable developer in a code-for-money project :( I'd have to employ/hire  
someone for assistance.

So, in case you point to a [patient!] developer then I can discuss details  
with her/him. Having some first hand experience with Hydra's VM would be a  
plus.

What I do from here is, to put things into a HydraVM (things which just  
check for the new conditions) to see where the time goes (effort as well  
as performance). But that will have very slow progress (the FlexDB project  
has priority for me at the moment).

If the above sounds interesting enough then I can email what was discussed  
with Igor (not excluding anybody ;)

> However, until such a time that there is a proposal I will drop this  
> pointless discussion since, simply put, there is nothing to discuss  
> here. The only available path at this point is by using one native  
> thread per image and consequently that's what's going to happen.

I fully agree with that path, it's the same for proposed CroquetMT.

/Klaus

> Cheers,
>    - Andreas
>




More information about the Squeak-dev mailing list