Some issues for single address space systems

We previously described Opal, an OS environment that has a single virtual address space common to all protection domains, rather than the usual private virtual address space per protection domain (e.g., a Unix process). All threads on an Opal node see the same mapping of virtual to physical addresses; any thread can reference any virtual address, but access to the data is determined by the thread's protection domain. The single address space approach is made feasible by the large virtual address spaces of the newest RISC processors. It allows protection domains to pass and share memory segments by mutual consent, while preserving the meaning of pointers. At the time Opal was a paper design, with only a few pieces of implementation. Since that time the key features of Opal have been prototyped. While the current prototype runs on 32-bit MIPS systems, it demonstrates that the model is both workable and useful. Yet the single address space idea remains a difficult adjustment, both conceptually and practically, for those of us long accustomed to per-process address spaces. Having spent much of the past year arguing the benefits of the model, our purpose now is to outline some of its limitations and complications. The goal is to separate the real problems from the false ones, and to focus the debate on the areas that we think are most important, based on our experience.<
>