"I first used image persistence but the image grow too large.."
thanks for reminding, Norbert.
Hi all,
perhaps you'll find me an idiot, I don't care.
(i know that I am: (class SelfReflection :o) )
Nevertheless, some brainstorming here.
I've brought this up before, but it seems nobody is interested in this
topic.. why?
it's about image size.
Currently, Pharo 1.3-13315 at my 4 Gigabyte Debian amd64 Linux machine
reports
memory 75,392,160 bytes
old 61,370,144 bytes (81.4%)
young 2,169,692 bytes (2.9000000000000004%)
used 63,539,836 bytes (84.30000000000001%)
free 11,852,324 bytes (15.700000000000001%)
(nothing peculiar added, just the Seaside package and a few classes of
my own. )
So, if i understand this well I have only 11,8 megabytes to play with?
To begin with: why is only 75 megabyte available in Pharo (or Squeak as
well)
when there is 4 gigabyte physical memory available on my machine??
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
--
Ted F.A. van Gaalen
Danketsweiler 608
D-88263 Horgenzell
Germany
T: +49 750 491 48 38
M: +49 151 587 862 47
