This paper presents our experience with building a cross-domain object invocation mechanism that is conscious about memory usage. Cross-domain object invocation issues are very similar to cross-domain procedure call issues. Although the cross-domain procedure call performance issues have been discussed widely, there is very little reference to issues regarding space. It is a typical example of a case where the issues arising in practice are more complicated than the ones described in the reference literature. Our mechanism is discussed in terms of the Spring modular operating system, but the same principles are applicable to other operating systems. The Spring system is a distributed computing environment running on a networked collection of computers. Each individual Spring system is based around a microkernel known as the nucleus. The nucleus is structured to support fast and secure cross address-space object invocations. Most of the traditional operating system services are provided by servers running as user-mode domains. In a system such as Spring, fast, secure, and space-efficient cross-domain invocation is extremely important. Argument buffers are used to pass data from one process to another. For fast cross address-space procedure calls the maximum size of this buffer should accommodate a small number of page frames. In typical contemporary architectures this size varies between 5 and 10K. In a system such as Spring, where there is a large number of active calls, this size leads to excessive memory usage. Earlier measurements have shown that at run-time the marshalled form of the arguments of most of the calls is less than a hundred bytes. Copying page size objects is the only notable exception. Our implementation uses small 128 byte buffers by default. A very fast mechanism is used to extend the small buffer for calls with marshaled arguments that do not fit in the small buffer. Therefore, it is very space efficient and does not affect the overall system performance. Measurements from our implementation that support these claims are presented.

A key problem in operating systems is permitting the orderly introduction of new properties and new implementation techniques. We describe a mechanism, subcontract, that within the context of an object-oriented distributed system permits application programmers control over fundamental object mechanisms. This allows programmers to define new object communication mechanisms without modifying the base system. We describe how new subcontracts can be introduced as alternative communication mechanisms in the place of existing subcontracts. We also briefly describe some of the uses we have made of the subcontract mechanism to support caching, crash recovery, and replication.