That was fun!
I didn't catch the beginning, so what is the core of Tim's idea to have a single process VM? I'm trying to imagine what advantages that would bring, but I'm coming up blank.
rado
|
On 12-10-13 4:05 PM, radoslav hodnicak
wrote:
That was fun!I'm not sure I caught it myself. Something about a single process vm, but I thought the vm was already single process. Then I sort of got the idea all the processes in the ProcessBrowser would be gone and there would be one process. This had to do with... I didn't get it, quite. Tim, what were we missing? Chris |
In reply to this post by radoslav hodnicak
The threads would be all light OS threads. Kind of like Andreas' "Hydra". Such threads which could be optimized in the hardware. Like Silicone Squeak I guess.
http://siliconsqueak.org/
- Darius ___________________ On Sat, Oct 13, 2012 at 1:05 PM, radoslav hodnicak <[hidden email]> wrote: That was fun! |
In reply to this post by Chris Cunnington
On Sat, Oct 13, 2012 at 2:02 PM, Chris Cunnington
<[hidden email]> wrote: > I'm not sure I caught it myself. Something about a single process vm, but I > thought the vm was already single process. Then I sort of got the idea all > the processes in the ProcessBrowser would be gone and there would be one > process. This had to do with... I didn't get it, quite. That's right, there would only be one Process... or, ultimately, no Process class, but just thisContext and its senders. The idea would be to get rid of concurrency within the image, and replace it with many images executing concurrently and communicating with each other. This would be an improvement for several reasons: 1. We'd have parallelism as well as concurrency. Each image/vm would run in a separate OS process, and potentially on different processors, allowing us to make use of multiprocessor hardware. 2. Since each image would have its own object memory, there would be no shared state between images, and that would simplify the programming model. We'd still have to worry about coordination between images, but we'd never run into bugs because of state being changed when we weren't expecting it. 3. It would be a better fit for the kind of hardware that we seem to be moving towards—highly distributed systems without a single coherent address space. Colin |
Something more like Erlang?
- Darius
|
In reply to this post by Colin Putney-3
On Sat, 13 Oct 2012, Colin Putney wrote:
> On Sat, Oct 13, 2012 at 2:02 PM, Chris Cunnington > <[hidden email]> wrote: > >> I'm not sure I caught it myself. Something about a single process vm, but I >> thought the vm was already single process. Then I sort of got the idea all >> the processes in the ProcessBrowser would be gone and there would be one >> process. This had to do with... I didn't get it, quite. > > That's right, there would only be one Process... or, ultimately, no > Process class, but just thisContext and its senders. The idea would be > to get rid of concurrency within the image, and replace it with many > images executing concurrently and communicating with each other. > > This would be an improvement for several reasons: > > 1. We'd have parallelism as well as concurrency. Each image/vm would > run in a separate OS process, and potentially on different processors, > allowing us to make use of multiprocessor hardware. > > 2. Since each image would have its own object memory, there would be > no shared state between images, and that would simplify the > programming model. We'd still have to worry about coordination between > images, but we'd never run into bugs because of state being changed > when we weren't expecting it. > > 3. It would be a better fit for the kind of hardware that we seem to > be moving towards—highly distributed systems without a single coherent > address space. In Erlang every process is lightweight (not 1:1 mapped to OS processes), so there can be many of them, because they're cheap (just like in Squeak now). Levente > > Colin > > |
More like chibi-scheme ... or goroutines in Go! ?
|
In reply to this post by Levente Uzonyi-2
On 14 October 2012 01:31, Levente Uzonyi <[hidden email]> wrote:
> On Sat, 13 Oct 2012, Colin Putney wrote: > >> On Sat, Oct 13, 2012 at 2:02 PM, Chris Cunnington >> <[hidden email]> wrote: >> >>> I'm not sure I caught it myself. Something about a single process vm, but >>> I >>> thought the vm was already single process. Then I sort of got the idea >>> all >>> the processes in the ProcessBrowser would be gone and there would be one >>> process. This had to do with... I didn't get it, quite. >> >> >> That's right, there would only be one Process... or, ultimately, no >> Process class, but just thisContext and its senders. The idea would be >> to get rid of concurrency within the image, and replace it with many >> images executing concurrently and communicating with each other. >> >> This would be an improvement for several reasons: >> >> 1. We'd have parallelism as well as concurrency. Each image/vm would >> run in a separate OS process, and potentially on different processors, >> allowing us to make use of multiprocessor hardware. >> >> 2. Since each image would have its own object memory, there would be >> no shared state between images, and that would simplify the >> programming model. We'd still have to worry about coordination between >> images, but we'd never run into bugs because of state being changed >> when we weren't expecting it. >> >> 3. It would be a better fit for the kind of hardware that we seem to >> be moving towards—highly distributed systems without a single coherent >> address space. > > > This is similar to Erlang's process model, but there's one big difference. > In Erlang every process is lightweight (not 1:1 mapped to OS processes), so > there can be many of them, because they're cheap (just like in Squeak now). In Erlang you can get away with this because of its ubiquitous immutability. But removing all concurrency from an image means that you can _today_ (without waiting for the VM support, in other words) start doing share-nothing message passing concurrency. It might be cheaper computing-wise to use green threads, but for us it might be (MUCH) easier to pay the computing cost of multiple images than trying to make things in the image immutable. For instance, Point is perfectly safe to share - mutating methods return new Points - but you can't share an Array without the mere convention of copy-before-changing. Even if one uses persistent data structures (something both Levente and I have done), you still have to rely on people not violating the contract of the structures (by exploiting a bug in the data structures, by breaking encapsulation through #instVarAt:put:, ...). And the cost of this violation is dear: random stuff breaks for no apparent reason. frank > Levente > >> >> Colin >> > > > |
On Sun, Oct 14, 2012 at 2:39 PM, Frank Shearar <[hidden email]> wrote:
In Erlang you can get away with this because of its ubiquitous Won't running dozens/hundreds of independent images that only communicate by messages return us to manual memory management? You could always return a newly computed copy of the data requested on each message but that could be a major performance hit as well.
rado |
On 2012-10-14, at 7:58 AM, radoslav hodnicak <[hidden email]> wrote:
> Won't running dozens/hundreds of independent images that only communicate by messages return us to manual memory management? You could always return a newly computed copy of the data requested on each message but that could be a major performance hit as well. I think it depends on the way the communication is organized. If it was based on remote messaging as in Spoon or E, then, yeah, we'd need some kind of distributed garbage collection. If it was channel-based, like Erlang or Go, then that's not as much of an issue. Of course, it also brings up the issue of managing image processes. They need to respawned when they fail and terminated when no longer needed. And if course we'd need dev and deployment tools to manage the swarm. It's more of a vision for the next decade than a plan for the next release. Colin |
Free forum by Nabble | Edit this page |