Squeak Community Meeting now

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Squeak Community Meeting now

Chris Cunnington
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

radoslav hodnicak
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


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Chris Cunnington
On 12-10-13 4:05 PM, radoslav hodnicak wrote:
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



    
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


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Darius Clarke
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!

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






Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Colin Putney-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Darius Clarke
Something more like Erlang?

- Darius


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Levente Uzonyi-2
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.
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).


Levente

>
> Colin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Darius Clarke
More like chibi-scheme ... or goroutines in Go! ?

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Frank Shearar-3
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
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

radoslav hodnicak

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
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

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


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Community Meeting now

Colin Putney-3
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