In Viengoos, a process's address space is managed entirely in user space by the process itself. This creates two interesting problems: dealing with circular dependencies resulting from having to manage the address space data structures and accessing and manipulating the address space data structures.

First, managing the address space requires resources, which in turn may require address space (e.g., data structures require memory which require address space, etc.). We currently break this circular dependency by trying to keep enough resources in reserve that allocating resources for managing the address space never requires more resources than are minimally in the reserve. The reserve is currently chosen in an ad-hoc fashion. It would be nice to determine it more systematically. Moreover, it would be nice to reduce the cases in which a reserve is required. This may be possible by restructuring some of the code.

Second, the address space data structures are protected using a single lock. This not only means that only a single thread can be updating the address space at a time, but that if a thread faults and the address space is locked, then the process dead locks! It should be possible to at least walk the address space using lock-free techniques. This requires updating the address space construction code such that all addresses remain valid during any given manipulation. Second, to avoid the mentioned dead-lock problem, we try to ensure that accessing the data structures will never result in a fault. This means protecting the stack. An alternative approach is to use undo buffers.

The current hash function in libhurd-ihash results in a lot of collisions when the hash table is 80% full. To overcome this, we keep hash tables at most 30% full. This represents a fair amount of overhead. Find a better algorithm. There can either be one that is appropriate in the general case or one that works well in a relevant, specific case, e.g., viengoos/object.c uses a hash to find the object corresponding to a frame, which is keyed on its physical address.

Note that this applies to the Hurd's libihash, too.

Modify, e.g., gcc to understand capability semantics and teach gcc how to optimize it, e.g., how to batch and combine calls.

This project is deemed suitable for a thesis.