<div dir="ltr">Hi Ben,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 8:29 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I am curious what are the issues holding us back from a multithreaded<br>
VM being mainstream, since I had a passing thought about a strategy<br>
for a partial-multi-threaded-VM.<br></blockquote><div><br></div><div>The issue is the image. The class library, the tools, etc are essentially single-threaded. Making the VM multi-threaded is only a relatively small part of the job. Rewriting the rest of the system to be thread-safe is a big job. Hence my focus on simply providing a threaded VM that supports sharing the Vm between threads so that any and all external calls are non-blocking. This is a really useful first stage. Maybe later economic activity around Pharo and/or Squeak will motivate and support work on a multi-threaded system, but that's on a further horizon than having the kind of interconnectivity a smaller first step provides. Further, Smalltalk's strong encapsulation is so good at providing a distributed programing framework which uses lots of interconnected images that that's also an attractive route to go that yields value with far less effort than a fully multi-threaded system, and of course is more generally useful.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I see multi-threading been prototyped before with RoarVM [1] & HydraVM<br>
[2], and the CogBlog project page [3] says "While multi-threading<br>
seems like an obvious and important direction to take the system in,<br>
making the VM multi-threaded per-se **does not provide any benefit<br>
before the Smalltalk image is made thread-safe** and that is<br>
probably more work than providing a multi-threaded VM. Hence a<br>
potentially more profitable approach is to concentrate on federating<br>
multiple VMs running multiple images, communicating through the<br>
threaded FFI."<br>
<br>
So I agree it would be a big job to make the whole Image thread-safe,<br>
but I wonder if a useful subset would be threads that are unable to<br>
disturb the system state? This might cover a lot of needs for<br>
parallelism, for example:<br>
* Complex force layouts with Roassal<br>
* Web server worker threads<br>
* Screen rendering by #fullDraw: & #drawOn:<br>
<br>
A copy-on-write facility might provide this, such that any required<br>
system state changes require manual coding in the parent-thread to<br>
process a result object returned from the child-thread when it exits.<br>
This might be implemented by combining Spur's new features for:<br>
* immutability<br>
* lazy become forwarding<br>
<br>
Implementation might require an extra object header bit WriteCopied<br>
and a new class CopyOnWriteThread known by the VM.<br>
<br>
Whenever a child-COWT reads an object, if WriteCopied is not set, set<br>
both it and the Immutable bits. Any thread writing to that object<br>
will trigger the existing immutability handler, which now<br>
additionally, when WriteCopied is set:<br>
1. Creates a new WriteCopiedIndirection object holding<br>
a. the old object<br>
b. the newly written object<br>
c. the thread that performed the write.<br>
2. Sets the old object's forward-pointer to that.<br>
<br>
Later the forward-following code observes the LocalCopy bit and based<br>
on matching the current thread with that stored in 1c. unrolls the<br>
correct object. The child-COWT leaves the WriteCopied bit set so as<br>
to avoid immutability being set again. Actually that precludes using<br>
real-immutability in a COWT, so my description above is not ideal -<br>
but hopefully is enough to show intent.<br></blockquote><div><br></div><div>Build it, they will come!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Could this avoid needing to make the whole image thread safe? and thus<br>
facilitate running Smalltalk worker threads across multiple CPUs?<br>
<br>
<br>
Actually, this might even be useful without running across multiple<br>
CPUs, since the cause of several intermittent Red-Screen-Of-Deaths was<br>
due to using multiple green-threads to improve UI interactivity. (For<br>
example forking update of Monticello lists to allow typing into search<br>
boxes. Here #drawOn: had "aList size" returning different values<br>
halfway through the algorithm. Where execution forked to provide this<br>
useful feature was the best place for code readability and intuitive<br>
understanding, but it was long path to trace through execution to<br>
discover the coupling between there and the rendering code. Certainly<br>
the fix is less readable that the original.)<br>
<br>
[1] <a href="https://github.com/smarr/RoarVM" rel="noreferrer" target="_blank">https://github.com/smarr/RoarVM</a><br>
[2] <a href="http://squeakvm.org/~sig/hydravm/devnotes.html" rel="noreferrer" target="_blank">http://squeakvm.org/~sig/hydravm/devnotes.html</a><br>
[3] <a href="http://www.mirandabanda.org/cogblog/cog-projects/" rel="noreferrer" target="_blank">http://www.mirandabanda.org/cogblog/cog-projects/</a><br>
<br>
cheers -ben<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>