<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael van der Gulik wrote:
<blockquote
cite="mid:1b61adf40904291557m1cb68432n8364e5de6442f360@mail.gmail.com"
type="cite">
<pre wrap="">On 4/29/09, Igor Stasenko <a class="moz-txt-link-rfc2396E" href="mailto:siguctua@gmail.com"><siguctua@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
LOL, did I miss a smiley? Doesn't sound trivial to me.<br>
<br>
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).<br>
<br>
(BTW, there is an ongoing discussion on GDAlgorithms
(<a class="moz-txt-link-abbreviated" href="mailto:gdalgorithms-list@lists.sourceforge.net">gdalgorithms-list@lists.sourceforge.net</a>) 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).<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<blockquote
cite="mid:1b61adf40904291557m1cb68432n8364e5de6442f360@mail.gmail.com"
type="cite">
<pre wrap="">
*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???)
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.
</pre>
</blockquote>
<br>
</body>
</html>