There are many directions to pursue beyond this initial work. The most promising endeavor, in terms of novel research, would be to provide accounting and control over the resources used by the garbage collector, although this is addressed to some extent by KaffeOS (described in Section 6.1.2). The second major effort would be to provide a formal analysis of Alta's type system and prove type safety under this new system. These future directions and several others are explained in detail in this chapter.
In a system that enforces total separation of processes, it is quite easy to "clean up" after terminating a process as there are no interdomain references to keep track of. The majority of resource accounting problems stem from fine-grained object sharing between domains with different resource principals. The current design for Alta provides processes with mechanisms to control interdomain sharing, but Alta only accounts for shared resources in a very simple manner.
The first weakness in Alta is exposed at object allocation time. The thread allocating the object is charged for the object's memory. This policy is generally good enough, but does not work if, for example, a server allocates an object and passes it to a client--there is no way to transfer the memory cost of the object in Alta. Alternatively, charging an object's memory to the processes that use the object might be more representative of the actual memory costs involved, but could lead to asynchronous memory exceptions. For example, consider a large object to which many domains hold a reference and where each domain is charged a portion of the total memory cost; if many of the domains release their reference to the object, the memory cost for the remaining domains will increase. Asynchronous exceptions resulting from such increases would make the already complicated task of writing multithreaded code far more complicated.
The second resource-related weakness is that Alta makes no attempt to charge particular processes for the resources required to run the garbage collector. This weakness makes Alta vulnerable to poorly-behaved or malicious processes, and weakens the system's ability to provide strong quality of service guarantees.
For example, if a process A has a small working set, a small memory limit, but a high allocation rate, it will necessarily invoke the global garbage collector frequently. Other processes in the system will be paused as the GC runs. Note that parent processes can constrain the number of invocations of the GC made by a process, but A should be able to collect its own heap without impacting other processes. One potential solution might be to restrict a process to an allocation rate, thus restricting the amount of garbage a process can potentially generate and indirectly constraining the work the garbage collector might need to do.
The simple statements defining Alta's type system in Section would benefit from a formal analysis that proves the assertion that type safety in Alta cannot be compromised by colluding processes. The formal analysis of the current Java class loader system in [31] should provide terminology and a good basis for the proof.
There are several scenarios where the dynamic nature of Alta's IPC-based class name resolution provides unused flexibility. For example, if a parent process simply wants to deny access to all packages other than the standard java.* packages, or simply wants to remap a few particular classes to customized IPC-based classes, then the full set of class name mappings could be statically specified when the child process is created. This has the advantage of reducing the run time overhead for loading a new class. Additionally, a static class mapping scheme would provide the virtual machine with more information about how types map from one process into another. This information could be leveraged to make the rules on sharable types more flexible, specifically loosening the restriction on nonpolymorphic field types.
The problems brought to resource accounting by interdomain references (see Section 3.2.5) could be alleviated by enhancing the virtual machine to support reference revocation [4]. For example, the Alta kernel could explicitly erase references to objects in a dying process, which would ensure that all of the objects owned by that process are successfully reclaimed. This would have the advantage, similar to a traditional hardware-based system, that the system could kill a process and all of its shared objects and be guaranteed that all of the objects would be reclaimed.
Supporting reference revocation would require solving a number of other hard problems [4]. First, finding all of the references to a revoked object would be difficult, especially in the face of C code running in the virtual machine and references on thread stacks. Additionally, the semantics of a thread executing in the context of a method on a revoked object are not clear, and the ramifications of revoking nontrivial objects such as threads, class loaders, and classes are also very complicated. Finally, the overhead of tracking object references (or finding all references on demand) would probably be great.
Because Alta and Fluke share many of the same fundamental abstractions, combining the two systems into a mixed enforcement environment should be possible. In this mixed environment Java processes could intermingle with hardware-separated processes and could control each other's resources. For example, a Java-based web server could create a hardware-enforced subprocess in which untrusted binaries could be executed, or a native database system could create a Java-based subprocess that contains and manages client queries written in Java. The simplest approach would be to restrict interlanguage communication to a common, purely IPC-based protocol. A more ambitious project would be to unify the memory and CPU scheduling abstractions to make for more seemless interaction between Java and native code.
Another area of future work is to design and implement applications that take advantage of Alta's sharing model to provide unique and inexpensive services. For example, a file server in Alta could be implemented entirely in Java libraries. The shared file cache code would be executed entirely by clients; type safety would guarantee the integrity of the file cache and the file system. A system that truly exploits this sharing model would contain completely stateless servers that do no work and consume no resources "on their own"--all of the resource consumption is done by libraries in clients. The server, if any still exists, merely coordinates and maintains persistent information that outlasts individual clients.
One of the difficulties faced by such a system would be synchronization in the face of asynchronous process termination. The kernel is able to solve this problem by postponing asynchronous exceptions, but such a mechanisms is necessarily unavailable to arbitrary (i.e., untrusted) user mode servers.