Is ColdStore Open Source?

colin@field.medicine.adelaide.edu.au colin@field.medicine.adelaide.edu.au
Thu, 10 Dec 1998 10:48:12 +1030 (CST)


I'm one of the designers and implementors of ColdStore, and I guess I can speak for us.

> E is currently implemented in Java, but we are interested in finding alternatives.

I have only the most fleeting knowledge of E, so please correct any inaccuracies or misapprehensions which become apparent in this.

I would like to say that, since I presume E is a byte-code interpretive language, I'd be loathe to implement too much of it in another byte-code interpretive language, as my limited experience of double-interpretations suggests that you can pay a performance penalty (to qualify this, my experience in double-interpretation is limited to a language interpreter written in Wang BASIC in the early 80s :)

Still, you may be relying upon there being a Java machine, or on Java->native compilation to get you the speed you need; you may reason that a distributed system is limited by net-speed rather than processing speed ... I don't know, and it's not my immediate problem.

> We've rolled some of our own persistence code, but it still needs a lot of work.  (The persistence code is temporarily unavailable for download.)

> An alternative platform that already provided good persistence would be wonderful.

Ok.  We've got a tripartite layered implementation.  At the bottom layer we have a virtual memory manager which handles persistence really well, wraps malloc()/free(), new()/delete() and (soon as I get around to it) new[]()/delete[](), gives you allocation debugging, and lets you play with spatial locality awareness in allocation.

We're committed to the idea that each of the three layers should present a usable and valuable interface.  I can't see why you couldn't just slot that in right away.  If you have thoughts on specific requirements you have for persistence, please let us know, as we're happy to extend to cover good ideas.

Layer 1: The second layer is a C++ class library wherein each object exports an identical virtual interface (modelled broadly on Python's API) and provides containment classes, iterators, mapping and such.  The code here hasn't been tested in anger: it's alpha.  The idea of this layer is to provide a framework within which one can add new functionality to a language by simply wrapping elemental functionality at layer 1.  Things like multi-precision integers should just drop in.

Layer 2: The third layer (and this is designed, but not implemented) is intended to be classes defined in the Layer 1 framework which are intended to support the general problem of implementing byte-code interpreters (such things as Frames, Exceptions, Interpreters), and language-specific classes (such as the Object model for the target language) all can possibly be implemented in terms of Layer 1 functionality (a Stack is just a kind of List, after all.)

We foresee this layer as being able to efficiently implement languages like Java, smalltalk, tcl, Python, etc etc.

No doubt E could eventually partake of this layer too.  It'd be a matter of writing a concrete mapping from some set of byte opcodes to some set of Layer 1 object method calls and C++/C functions, then implementing E's object model (and other language specific things) at Layer 2.  It'd be nice to contemplate a Capabilities class at Layer 2, too, so that each language could partake of some of E's facilities.

As you may notice, we're interested in peer relationships between languages, and mosaic solutions to problems.

> From a brief glance at http://field.medicine.adelaide.edu.au/coldstore/colddesign.html it seems your system might be a candidate implementation substrate, but I could find no information about its intellectual property status.
> E is open sourced under Mozilla, so we'd require an open source license compatible with Mozilla.
> This includes most of the standard ones, including LGPL I believe, but excludes GPL.

We'll be releasing QVMM (Layer 0) under (we think) Netscape's PL (Mozilla) around Jan1st 1999.  We'll be releasing Layer 1 as soon as we've undergone a planned convulsive simplification of the API, and clean up the code a bit.  We've got everything we need, at that level, but a Hashing Dictionary type, consideration of which has lead us to revise the way all the mapping types (currently, mainly, BTree and Namespace) are implemented.

> Btw, If we did find a suitable alternative, we would probably end up on this substrate *in addition to* Java, rather than *instead of* Java.

Your decision entirely, of course.  Personally, I think it'd make more sense re-implementing Kaffe in terms of ColdStore, and then peering E and Java (and whatever else ends up implemented in ColdStore) but I am admittedly biased.

> My current favorite candidate is the Squeak virtual machine.
> If you could say how your's compares to their's, it would be most helpful.

Thanks for making me have a serious look at Squeak.  Quite a lovely system overall.  I see its main value being well above its virtual machine.  I think, perhaps, I could mark the difference most clearly by pointing out something fundamental and simple:

        Squeak defines pop()/push() and so on as primitives.  In ColdStore, they're behaviors of a Stack object defined at Layer2.  ColdStore's designed to efficiently implement multiple virtual machines over the same persistent store. 

        Squeak defines BitBlt operations as primitives.  In ColdStore, they'd be implemented in terms of (probably) a BitBlt object at Layer1, present a consistent interface, and be usable by other peer VMs.

So Squeak is both higher and lower level than ColdStore.  Perhaps I should rewrite the documentation to call ColdStore a VM Toolkit.

Colin.