Quoting Sebastian Sastre ssastre@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