[squeak-dev] Smalltalk and flash memory

Louis LaBrunda Lou at Keystone-Software.com
Fri Jun 6 22:24:35 UTC 2008


Hi All,

I am sorry for the length of this post and its slow start.  Please bear with me
as I think you will fine it interesting.

I have been thinking about how the recent and continuing advancements in
persistent memory (flash memory) in terms of speed, size and cost may impact
Smalltalk programs.  The available speed and sizes are increasing and the prices
are dropping.  There are already products that use flash memory to replace disk
drives.

Many programs maintain data in a database.  Often this is an SQL database,
sometimes it is an object database.  In either case it is not as easy to
maintain the data in these databases as it is to maintain data, as in memory
objects.

A Smalltalk program running on a server with a large amount of flash memory,
could run without the need for another form of database.  The flash memory would
be in addition to the normal memory, with both available as RAM.  The flash
memory would not look like a hard disk replacement.

To do this the Smalltalk VM would need a means of accessing the flash memory
differently than normal memory and would need a way of "reconnecting" to the
flash memory upon a system restart.  If the OS knows about the flash memory
there would need to be a means of connecting the flash memory to one program or
another.  The OS/program interaction can be addressed in many ways, I won't go
into them here.  Lets just say there is a need for an OS/program interaction,
and that need can reasonably be met.

I would like to talk about the Smalltalk VM and its role in this new
environment.  I don't know a lot about the workings of Smalltalk VMs, so I will
only talk about it at a very high level of functionality.  If a program could
tell the VM to instantiate an object in flash memory, based upon an indicator as
to whether an instance is to be persistent or not, the need for database
specific code almost disappears.  The indicator to be persistent could propagate
down to any instance pointed to by a persistent (in flash memory) object.  The
VM would need to be smart enough to move instances from regular memory to flash
memory when needed.

A program would only need to identify a few instances of collections
(LookupTable, Dictionary, SortedCollection etc.) as persistent object and it has
a database.  The code would change (or add to) these objects as it normally
would, without care for saving them in any other way.  There would be no need to
serialize an object to save them in any kind of an object database.  The
database is just the objects in the flash memory.

The flash memory would be RAM and NOT a disk replacement.  I don't know this for
sure but I don't think there are currently any motherboards that can have direct
CPU instruction access to large amounts of flash memory as if it is regular RAM
but I don't think it would be hard to do.  I would expect a 64 bit CPU is
needed, so we could have direct access to many gigabytes of flash memory beyond
the 4 gigabytes available with a 32 bit CPU.  

Different Smalltalks like VA Smalltalk and Squeak might deal with the flash
memory differently.  VA Smalltalk programs (not the development environment but
packaged images) don't normally save the image between runs.  Squeak is a more
traditional Smalltalk where programs aren't packaged the way VA Smalltalk
programs and the development environment and run time image are often the same
and the image is saved between runs.  In a Squeak program the objects in the
flash memory would probably not need to be save to a hard drive with the rest of
the image.

I think that what I am proposing could also work with any language that uses a
VM to support objects.  I would prefer Smalltalk to do it first.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com




More information about the Squeak-dev mailing list