Hi Ted, You have done a good job of describing what GemStone/S 64 Bit provides. Your 'image' size is essentially limited to disk that can be connected to one machine. Collection classes have been enhanced with B-Tree indexes that are automatically updated when objects are modified. Multiple VMs can connect to the same image and each is provided with a consistent (isolated) view. Views are updated at transaction boundaries. Updates are done in a transaction with each transaction recorded to a separate log for disaster recovery. There is no need for an external database, since you have a persistent, transactional image that can be shared across multiple machines. Existing users have images of hundreds of GB in size with hundreds of VMs. Check it out at http://seaside.gemstone.com/. James
I've brought this up before, but it seems nobody is interested in this topic.. why?
it's about image size.
...
Anyway, IMHO this very limited storage violates the Smalltalk-all-in-one image ideal, because with this limited storage one cannot avoid the use of external data stores like databases (of course, exception: there always will be import an export of objects/data)
External data storage is complex, unreliable and should be something of the past. I'd suggest: don't waste time with this. rather improve the Smalltalk internal data handling.
I wish to have a very large image so e.q. I can have an entire company's administration (client and accounting data etc.) alive in it. I want to use Collections and descendants, not external databases. So, everything within the image.
The beautiful (although opinions may vary) principle of a Smalltalk environment is Image Persistence, isn't it?
IMHO this requires: - virtually unlimited image memory size. -no external databases like e.g. Mongo or DB2 whatever. -no persistent external storage at all.
-You should see the (currently still) faster database performance as a challenge to improve the Collection and other related data handling classes
-You would have to completely restructure the architecture. or just extend the address width: 64 bits?
what about an image of virtually unlimited size > gigabytes so
(for now, if it goes beyond the physical memory size (say 32 GB?) one could use a VM that works with virtual storage based VM Virtual storage was first in use successfully with IBM mainframes in the 1970s (and still is) )
on the other hand, I estimate holographic? physical memory going in Terabytes is about to be available in 5-10 years from now. blindingly fast, compared with today's standards.
So, one has about 5 years to come up with such a system :o) if one does, Smalltalk is ahead of everything then..
Don't laugh. One didn't even dream of 4 gigabytes of memory during the Commodore 64 era. 1982-1994.
In short: what would have to be changed to enable this?
Some thoughts and speculations? Anyone for tennis?
Thanks Ted