I've been doing a lot of research and thinking about the upcoming s5 design, and at Reed's request I'm going to try and sketch out what I've been working on.
-- Let me first emphasize that the key ideas behind the vobject model have been shown to be powerful and robust. The essential concepts of a network-neutral message-passing system, associative hyperlinks between objects, and the ability to associate of multiple types (behaviors) with a single logical vobject have proven their worth. We have been able to rapidly develop a variety of tools culminating in Ter'Angreal, the 3D browser, as well as apply the underlying infrastructure to other systems such as the Web. Having thoroughly explored the problem space, we discovered a few things that could have been done better. Thus, the key areas driving s5 design are the following: 1. Footprint 2. Concurrency 3. Scripting 4. Security I will discuss each of these ideas in a separate email, starting with the first one here. 1. Memory footprint The current s4 design has a lot of per-vobject overhead, leading to a significant memory footprint. The development version improves on this a bit, but the honest truth is that the implementation was not written with memory efficiency in mind. The s5 design will attempt to address in various ways, including attempting to directly minimize the byte count of crucial classes and data structures, and by using the "flyweight" pattern to collapse identical classes into a single shared instance. In particular, symbols (method names, message fields, types, etc) will be stored in a single global symbol table. This will ensure that such strings (which are expected to be used a lot in the system) are not duplicated, and has the convient effect of also making string comparison a constant-time pointer comparison instead of a linear time compare. Another method for making the most out of the memory will be the ability to load vobjects from persistant storage on demand, and swap out rarely used vobjects. This will allow a site to contain many more vobjects than would otherwise fit in RAM. This To reduce the footprint of vobjects themselves, I am introduce a concept called "embedded children". These are objects that appear in protocol terms to be independently addressable vobjects that can send and receive messages, but are actually stored as a field of another vobject. This emerged from the observation that while it was extremely powerful from a design pattern standpoint for properties to be first-class vobjects, in s4 this often led to situations where it hundreds of bytes of overhead to store even a single four byte integer (for example). As an embedded child, the child vobject is simply a normal data field in the parent class, and it falls upon the parent sends and receives messages on behalf of the child. A final goal is to simplify memory management overall. One significant change will be the introduction of a single root to the vobject tree. In s4, the site contains a list of every vobject on the site, and the site URL + vobject site name acts as the unique identifier for a vobject. Unfortunately, there are two problems with this. The first is that typing "ls" in mesh in the site root on a large site results in it printing out 1000s of vobjects to your screen, which is rarely useful. The second, more subtle problem is that vobjects are easily leaked by orphaning them so that no other vobject points to it but failing to to call excise() on it. In s5 I propose to change this system, to a design inspired by the design of the Unix filesystem. Vobjects will have unique, opaque identifiers (which correspond to inodes) that are not generally visible to the user, and vobjects will be reqired to be accessable from the site root via some path. Vobjects which are orphaned can then be garbage collected. Other strategies to make memory management easier will include a greater emphasis on copying semantics when the amount of memory involved is small. This avoids having to maintain reference counts, and we can keep simple data structures on the stack (and in L1 cache?) to avoid potentially expensive calls to the heap allocator. Minmizing the memory footprint is a key goal to ensure scalability, but perhaps even more important will be the ability to support concurrent and asynchronous processing, which I will talk about in my next email. -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
