[Vm-dev] Copy-on-write for a multithreaded VM
eliot.miranda at gmail.com
Fri Jul 17 05:02:35 UTC 2015
On Thu, Jul 16, 2015 at 8:29 PM, Ben Coman <btc at openinworld.com> wrote:
> I am curious what are the issues holding us back from a multithreaded
> VM being mainstream, since I had a passing thought about a strategy
> for a partial-multi-threaded-VM.
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.
> I see multi-threading been prototyped before with RoarVM  & HydraVM
> , and the CogBlog project page  says "While multi-threading
> seems like an obvious and important direction to take the system in,
> making the VM multi-threaded per-se **does not provide any benefit
> before the Smalltalk image is made thread-safe** and that is
> probably more work than providing a multi-threaded VM. Hence a
> potentially more profitable approach is to concentrate on federating
> multiple VMs running multiple images, communicating through the
> threaded FFI."
> So I agree it would be a big job to make the whole Image thread-safe,
> but I wonder if a useful subset would be threads that are unable to
> disturb the system state? This might cover a lot of needs for
> parallelism, for example:
> * Complex force layouts with Roassal
> * Web server worker threads
> * Screen rendering by #fullDraw: & #drawOn:
> A copy-on-write facility might provide this, such that any required
> system state changes require manual coding in the parent-thread to
> process a result object returned from the child-thread when it exits.
> This might be implemented by combining Spur's new features for:
> * immutability
> * lazy become forwarding
> Implementation might require an extra object header bit WriteCopied
> and a new class CopyOnWriteThread known by the VM.
> Whenever a child-COWT reads an object, if WriteCopied is not set, set
> both it and the Immutable bits. Any thread writing to that object
> will trigger the existing immutability handler, which now
> additionally, when WriteCopied is set:
> 1. Creates a new WriteCopiedIndirection object holding
> a. the old object
> b. the newly written object
> c. the thread that performed the write.
> 2. Sets the old object's forward-pointer to that.
> Later the forward-following code observes the LocalCopy bit and based
> on matching the current thread with that stored in 1c. unrolls the
> correct object. The child-COWT leaves the WriteCopied bit set so as
> to avoid immutability being set again. Actually that precludes using
> real-immutability in a COWT, so my description above is not ideal -
> but hopefully is enough to show intent.
Build it, they will come!
> Could this avoid needing to make the whole image thread safe? and thus
> facilitate running Smalltalk worker threads across multiple CPUs?
> Actually, this might even be useful without running across multiple
> CPUs, since the cause of several intermittent Red-Screen-Of-Deaths was
> due to using multiple green-threads to improve UI interactivity. (For
> example forking update of Monticello lists to allow typing into search
> boxes. Here #drawOn: had "aList size" returning different values
> halfway through the algorithm. Where execution forked to provide this
> useful feature was the best place for code readability and intuitive
> understanding, but it was long path to trace through execution to
> discover the coupling between there and the rendering code. Certainly
> the fix is less readable that the original.)
>  https://github.com/smarr/RoarVM
>  http://squeakvm.org/~sig/hydravm/devnotes.html
>  http://www.mirandabanda.org/cogblog/cog-projects/
> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev