> Quoting Sebastian Sastre <ssastre at seaswork.com>:
...
what do you think about this One Process Per Instance Smalltalk?
> 
> 
I'll answer an important aspect that just came to my mind: persistence.

Question: we won a persistence solution at the same price of making a one
process per instance Smalltalk?

Well lets see... "one crisis at the time"
 
I decided to interpret that all database madness is because the industry was
trying to think is normal to share writes. And I decided to interpret that
the shared write is not normal but a trade off that was made in the industry
to win some usage at the price of "buying the concurrency problem" for us
all.

With One Process Per Instance we have put aside the shared-write so closed
the door to it's whole big space of problems.

I speculate about how an image of this Smalltalk would raise in a host with
the million objects of the intensely dense graph that Peter bring as
example.

Of course one million processes can't be reasonably run in a laptop of any
of us today so we are forced to think differently from how a current image
starts up today. So perhaps we can manage that million by taking 4K light
processes at the time in a let's say 4 core processor CPU with 4G of RAM.

But how this will work? Differently from an image of current smalltalk that
reifies all instances in RAM at startup, this will reify objects on demand
(lazily) in a swarm of instances of N thousand at the time. N will be
trivially and directly depending on the hardware resources.

And what happen when a demand of reaching an instance occurs? The VM assigns
a process and a little portion of RAM for that instance that will be stick
to it as long as it's reified and not garbage collected. Please note that I
said that only that process it's allowed to write. That only happens if not
previously reified. Once an instance is reified, so it has it's process
assigned and it's portion of RAM, it can receive the message.

And what happen when you save an image like that? The VM has assigned that
portion of RAM to that process but the system just gives a different support
(medium) for that piece of RAM. It trivially maps RAM to disk. No impedance
mismatch. Just the instance format plus a way to locate it when needed
again.

So? Well.. that way every piece of RAM dedicated to an instance has an
homologous dedicated piece of disk.

And? And that piece of disk can only be written by the process of it's own
instance provinding guarantee that it never ever ever never ever will be
inconsistent.

Oh.. so we won a persistence solution at the same price of making a one
process per instance Smalltalk? I have serious doubts about fault tolerance
to power faliures and such but putting that in a second plane I'm starting
to think that yes we do because a commit will be a mere flush of that disk
or medium and you never need to rollback anything just write or do not do
it.

Intriguing...dont you think?

Sebastian Sastre