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
Locked
