2009/4/30 Joshua Gargus <schwa at fastmail.us>:
> Michael van der Gulik wrote:
>
> On 4/29/09, Igor Stasenko <siguctua at gmail.com> wrote:
>
>
>
> As for moving to multi-cores.. yes, as Gulik suggests, its like adding
> a new dimension:
>  - local scheduler for each core
>  - single global scheduler for freezing everything
>
> This, of course, if we could afford running same object memory over
> multiple cores. Handling interpreter/object memory state(s) with
> multiple cores is not trivial thing.
>
>
> Implementing it isn't hard. It's fixing all the bugs we'll find that's
> hard. There'll be bugs in the image and in the VM, and it'll be a good
> 30 years before we've found them all.
>
>
> LOL, did I miss a smiley?  Doesn't sound trivial to me.
>
> With great effort, I will avoid getting into another long thread about how a
> Hydra-like model is more suitable to the memory architectures of future
> multi-core processors (Nehalem is already splitting up the L2 between cores
> instead of making it uniformly accessible to all cores, and this trend will
> continue).
>
I wouldn't say that implementing it would be hard.
If you have a clear vision what it should do and how, then its only a
question about how fast you type.
The 'hard' part is the tough decisions you have to make along the road, like:
- what to do with lookup cache? If each thread holds own cache, then
when you installing new method, how to make sure that you flush all of
them in atomic fashion? And if you leave a single global cache - how
to make concurrent access to it to be not the bottleneck of whole
system.
I think that implementation of multicore VM will be a waves of
triumphs and failures, when you think its done, something will stab
you in the back. :)

> (BTW, there is an ongoing discussion on GDAlgorithms
> (gdalgorithms-list at lists.sourceforge.net) about task-parallel multithreading
> architectures to take full advantage of multi-cores.  The subject is
> "General purpose task parallel threading approach".  C++-centric, but still
> interesting; game programmers do know how to eke performance out of their
> hardware).
>
> Cheers,
> Josh
>
>
> *Most* parts of the VM will continue working fine. The parts that will
> break... er... some of the parts that will break are:
>
> * garbage collection.
> * allocating memory for new objects.
> * primitives and devices.
> * pointer swapping *might* need to be atomic (become:, becomeForward:).
> * Semaphore signalling.
> * (more things???)
>
there's always (more things???). It adds a new dimension to every
single algorythm which were invented for running in non-concurrent
environment.

> Most other things should work fine if we fire up a second interp() on
> another pthread which shares the same object memory.
>
> Writing to object slots (aka instance variables) should continue to
> work fine provided that the write itself occurs in a single atomic
> machine code instruction and that the object that the new reference
> points to is already allocated and initialized.
>
> Creating new objects could be improved by having each scheduler have
> it's own eden space. But then the garbage collection becomes more
> complex. The other alternative is to have a global image lock and
> whoever whines about it can implement a better solution.
>
> I think that's it. The only important thing shared between different
> OS threads (pthreads?) would be the object memory, and all you really
> do with the object memory is write or read from object slots, create
> new objects and run garbage collection.
>
> Also, it shouldn't always be necessary to freeze the entire image. If
> every scheduler has its own eden space and its own list of processes
> that nothing else is allowed to modify, then there's no need to freeze
> the whole VM for scheduler work. The only time the whole VM will need
> to freeze is for garbage collection, but even being very intelligent
> with a new GC design can avoid that.
>
> Gulik.
>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.