[Vm-dev] Re: A Smalltalk object database idea
stephen at pairhome.net
Tue Dec 29 17:23:12 UTC 2009
On Tue, Dec 29, 2009 at 11:56 AM, Louis LaBrunda
<Lou at keystone-software.com>wrote:
> Hi Stephen,
> Thanks for the reference. OOZE and maybe LOOM (I couldn't see much about
> LOOM) seem to be virtual memory for objects. A way to expand the size of
> memory. I'm talking about an object database built with virtual memory
> ideas. I know databases are ways to expand the size of memory but I'm
> looking at their persistence feature and not making memory look bigger.
Yes, I know, but you will find that you will face many of the same issues
that OOZE and LOOM dealt with. I actually implemented a system much like
what you are describing in squeak a number of years ago. I used BerkeleyDB
as my object storage. It was possible to connect multiple squeak processes
to a common database. There was a transactional system that let me track
changes to disk based objects and commit them. You could work with disk
based objects transparently. Working with the squeak VM was challenging in
the sense that it is all very highly tuned for optimal memory use, fast GC,
etc. I had to perform a lot of system tracing to transform squeak images to
my new object memory layout, etc. To fault in objects quickly, I had to
implement a fast become operation. Since squeak has no object table, I
implemented a forwarder capability that would transform any object into a
forwarder to another object by setting a header bit, then using the class
pointer to point to the target object (which then necessitated doing away
with the compact class header format). GC would sweep the forwarders away
when it ran. IIRC, I managed to this with something like a 10% performance
and memory hit.
I got to a point where I realized I needed to also be able to persist
classes and move them among different squeak images that might have
different versions of like named classes and so forth (so you get into
namespace issues). I eventually ran out of steam and abandoned the project.
Croquet was also just starting up at the time, so I felt they would
eventually solve many of these issues.
With that experience, I now believe you really need a new language (that
deals with namespace and security issues ala Newspeak) and COLA (VPRI
research) like VM architectures (that are easily customized) to explore
things like this...I'm hoping such things are not that far off.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev