Andreas,

> That is actually great news. I had absolutely no idea that the Self 
> scheduler was implemented in Self (I had naturally assumed it was 
> implemented in C).

Given that even their parser (what they call the part that translates
source text into bytecodes) is in C++, it is natural to assume that the
scheduler would be as well. But it isn't the case.

> The fact that it uses the same idea is a great 
> validation of our thoughts here ;-)

Exactly my point - it is always great to find a working example of
something you are thinking of doing. Anyone wanting to do multicore work
in Squeak should really watch David Ungar's talk at the OOPSLA 08 Squeak
BOF, for example.

> Do you by any chance know how Self 
> performed in heavy process switch benchmarks? Has anyone ever assessed 
> the overhead of the scheduler?

I think my friend's PhD project was probably the application which
stressed the scheduler the most, but I don't think he made any
measurements. Note that with the adaptive compilation technology, it
probably was no slower than a VM based scheduler. But I think it is
likely that it wasn't a hotspot and so the good compiler never got to
it, in which case the performance didn't matter.

Normal Self applications are based on Morphic and tend to be single
threaded. Given that Self doesn't have exception handling, for every
pass through the world redraw code a background thread was started up to
detect when the drawing logic go into an infinite loop. That would be
some 30 new threads being created and destroyed per second (normally
doing nothing but waiting for a timeout). I imagine we would need at
least a hundred times that before the scheduler performance would have a
significant effect.

-- Jecel