On Tue, Dec 29, 2009 at 11:56 AM, Louis LaBrunda <span dir="ltr"><<a href="mailto:Lou@keystone-software.com">Lou@keystone-software.com</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Stephen,<br>
<br>
Thanks for the reference. OOZE and maybe LOOM (I couldn't see much about<br>
LOOM) seem to be virtual memory for objects. A way to expand the size of<br>
memory. I'm talking about an object database built with virtual memory<br>
ideas. I know databases are ways to expand the size of memory but I'm<br>
looking at their persistence feature and not making memory look bigger.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>- Stephen</div></div>