> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Igor Stasenko
> Enviado el: Miércoles, 24 de Octubre de 2007 17:32
> Para: The general-purpose Squeak developers list
> Asunto: Re: Multy-core CPUs
> 
> Sebastian, you can envision that any unique object in VM is a 
> unique process. No changes required to VM. Your concept 
> having zero worth for me, because VM already supports that 
> each objects have own encapsulated state, and you can change 
> object's state only by  sending messages to it.
> So, we already might say, that all objects are living and can 
> be represented as a processes which triggered by sending 
> message(s) to them.
> 
Well seems to me that you are very near to get the idea. You have described
what we do have now. You seems to be missing the part of the process. I'm
saying that an object has a double nature. It is an object as we know it
today but it lives not statically (like in a photography) but in a process.
And I'm stating that this relation exists by nature. It's the result of
coupling the concept of object with the concept of process. Now we can
cleverly clamp the process part of it and somehow invent a support that maps
this process part nature of the object in some process running in some core
of this incoming hardware.

I think that was with Spoon, I can't recall well now but someone of this
group has made a visual Smalltalk memory map with it's instances. Just to
have an idea try to visualize an instance. It is supported somewhere in RAM
right? Metaphorically it has one "foot" step firmly in RAM. Currently some
VM process, anyone, can tell it to modify itself and it writes in it's piece
of RAM. Ok, now the idea I'm exploring and trying to communicate here it's
that objects should (metaphorically) have "two foots". One in RAM and the
other in a process running in some core. But that VM *will do guarantee*
that every instance has it's piece of RAM as usual and a process that will
be guaranteed to be the only one writing in that piece of RAM: the process
that *is* the process part of the double nature of the instance. 

As someone properly already stated: no sharing memory no concurrency
problems.

Now.. what I think is a good question to answer regarding to this
hypothetical Smalltalk is how do we translate this conceptual model to a bit
based model to make it fit our current (incoming) hardware?

I bet that the VM will have to be modified.

As you properly said the current VM guarantees that the state of an object
can be only be changed by sending it some message. What it is not
guaranteeing right now is which process of that VM will be the one that will
send the instructions to do the write. So now could be any VM process. And
<metaphor> that's how we have purchased the concurrency problem </metaphor>
we are trying to solve now. 

But once again: what I'm saying here is about a VM that guarantees which
process write that piece of RAM: the only one that is assigned to that piece
of RAM belonging to that instance.

Why we "purchased" that concurrency problem? Becaouse a trade off
prioritizing pragmatism with the resources available at that time. We
polluted the conceptual domain with implementation matters (the need to make
N process share in read/write the same space of RAM) to be able to get what
we get today with the hardware we have today. But may be ideas like this
using better hardware can depollute it.

See: mathematis are nothing but a tool to model. All models are rudimentary
simplifications of some system. Make a limited model reality with boolean
algebra may tehoretically be possible but extremelly unhuman. Programing in
assembler is a paliative to walk that path with less "brain damage".

Smalltalk is also a tool to model. The difference resides in it's nature: it
is heuristic by design. It's intellectually ergonomic. It shows respect to
the form in we humans form thought and concepts, mature old ones by refining
and explore new ones by prototyping, and relegates to a secondary place how
machines need (this couple of decades?) things to be done so they obey
behaving as we need.

So Smalltalk pays a price of being less efficient (than C, etc) to bring you
the freedom of maping what you see in reality directly to a computer. It
frees you from having to map it to mathematics to reifi it later even more
polluted (one order of magnitude of distorsion in the modeling). 

That way you can model keeping minimalized the machinery madness so you gain
the chance to make a less polluted virtual model by maping the model your
brain quickly makes 1:1 with the virtual model computers need. It breaks the
trend to model things booleanly, mathematically even relationally. It gives
you a tool that can make your concept be from timidly fragile and embrionary
maturing to rock solid to go for production: that tool is the virtual
object, an instance.

Current hardware is based on mathematics. Boolean. So we had no other option
in that trade off than to take the boolean path to be able to use hardware
to make a Smalltalk opening computers to a bigger, and closer to humans,
space of solutions.

Maybe hardware is reaching a point in which, excuse my french, it sucks
less. And we can give a step backward in that old, absolutely
understandable, trade off and regain the conceptual refinement we allways
needed in this system. Somethig that maybe was seen there in time or may be
is being seen now because it's time to reach a new degree of subtlelty of
cogitation of this clever artifice we know as Smalltalk.

Returning to planet Earth now.. In the idea I'm exploring here, the VM of
this hypothetical Smalltalk you will also have guarantee that the process
that sends intructions to write in memory is the one that belong to the
instance that belongs to that process [1]. That way you never got
inconsistent states nor concurrency to write there because you never shared
anything [2].

That VM should make the processes of the instancess in a fashion that does
not matter in which core it's running, so it can be balanced, nor what part
of the RAM has assigned. Once assigned will be for it and only it. It will
be written by that process and only by that process.

I care about passing this message right so I ask you kindly: do you see
value now?

	cheers,

Sebastian

[1] the process belongs to the instance or the instance to the process? A
Moebius thing here? It's reasonable because I have somehow fusioned the
concepts
[2] in the brain analogy makes sense because you don’t share yours brain
memory. You "serialize" your thoughts, to written text or spoken words, but
you never ever ever share RAM which, at hardware level, are your synapses.