Peter Amstutz wrote: > 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.
This seems like a very good optimization, given how string-heavy the system is. Could string tables also be used to compress COD files more? How about network optimization by having two sites "share" a string table (or have a static standard string table of commonly used strings in the "core" protocol?). Also ... are properties stored as strings at the moment or as native bytes (I actually don't know this)? If they're stored as strings, compressing them to native data structures would probably be a big win too (same thing goes for properties with storing them in COD and sending them over the network). [I also had another idea related to network optimization -- which is unrelated to memory footprint. The idea is particularly for large worlds with lots of objects to listen to: instead of listening update messages sending the whole message string and object identification, etc, have an "optimized listen" protocol, where a chosen-at-runtime "tag" is used to identify a certain kind of update message coming from a specific object, and that's all you need to have in the network traffic (other than the actual updated values, of course). This could even be done transparently at the network interface level] > > 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 Could this also be extended to support persistant transparent caching of remote sites that have been visited? Perhaps paired with a new method to query certain information about vobjects, such as is-cacheable and last-updated/version? > > 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. Sounds reasonable... What reasons (other than asthetics/symmetry) are there for properties to be first-class? Will a property object ever have children? Will one ever be at site root with no other parent? Will one ever be a meta-object other than "property"? I guess you could have two parents sharing the same property if it's a big one ... > > 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. Yes. I've run into this "ls at site root" problem and it's a bit annoying :) And orphaned vobjects just seem like a lose. > > 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. I don't think I understand this one.... > > 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. > Scalability is going to be hugely important if vos is ever going to support a world-wide metaverse with large, interactive worlds. I'm glad you guys are going to be focusing on the issue from the ground up. -Ken _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
