-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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 dont 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.