rick@rescomp.berkeley.edu
We have ported the Nachos instructional operating system [1] to Java, and in the process of doing so, many details changed (hopefully for the better). [2] remains an excellent resource for learning about the C++ versions of Nachos, but an update is necessary to account for the differences between the Java version and the C++ versions.
We attempt to describe Nachos 5.0j in the same way that [2] described previous versions of Nachos, except that we defer some of the details to the Javadoc-generated documentation. We do not claim any originality in this documentation, and freely offer any deserved credit to Narten.
The Nachos instructional operating system, developed at Berkeley, was first tested on guinea pig students in 1992 [1]. The authors intended it to be a simple, yet realistic, project for undergraduate operating systems classes. Nachos is now in wide use.
The original Nachos, written in a subset of C++ (with a little assembly), ran as a regular UNIX process. It simulated the hardware devices of a simple computer: it had a timer, a console, a MIPS R3000 processor, a disk, and a network link. In order to achieve reasonable performance, the operating system kernel ran natively, while user processes ran on the simulated processor. Because it was simulated, multiple Nachos instances could run on the same physical computer.
Despite the success of Nachos, there are good reasons to believe that it would be more useful in Java:
Java is much simpler than C++. It is not necessary to restrict Nachos to a subset of the language; students can understand the whole language.
Java is type-safe. C++ is not type-safe; it is possible for a C++ program to perform a legal operation (e.g. writing off the end of an array) such that the operation of the program can no longer be described in terms of the C++ language. This turns out to be a major problem; some project groups are unable to debug their projects within the alotted time, primarily because of bugs not at all related to operating systems concepts.
It is much more reasonable to machine-grade a Java project than a C++ project.
Many undergraduate data structures classes, including the one at Berkeley, now use Java, not C++; students know Java well.
Java is relatively portable. Nachos 4.0 uses unportable assembly to support multithreading. Adding a new target to Nachos 4.0 required writing a bit of additional code for the port.
One of the first concerns many people have about Java is its speed. It is an undebatable fact that Java programs run slower than their C++ equivalents. This statement can be misleading, though:
Compiling is a significant part of the Nachos 4.0 debug cycle. Because javac compiles as much as it can everytime it is invoked, Nachos 5.0j actually compiles faster than Nachos 4.0 (running on a local disk partition with no optimizations enabled).
Generating large files on network partitions further slows down the debug cycle. Nachos 5.0j's .class files are significantly smaller than Nachos 4.0's .o files, even when compiling with -Os. This is in part due to C++ templates, which, without a smart compiler or careful management, get very big.
Type-safe languages are widely known to make debugging cycles more effective.
Another common concern is that writing an operating system in a type-safe language is unrealistic. In short, it is unrealistic, but not as unrealistic as you might think. Two aspects of real operating systems are lost by using Java, but neither are critical:
Since the JVM provides threads for Nachos 5.0j, the context switch code is no longer exposed. In Nachos 4.0, students could read the assembly code used to switch between threads. But, as mentioned above, this posed a portability problem.
The kernel can allocate kernel memory without releasing it; the garbage collector will release it. In Linux, this would be similar to removing all calls to kfree. This, however, is conceptually one of the simplest forms of resource allocation within the kernel (there's a lot more to Linux than kmalloc and kfree). The Nachos kernel must still directly manage the allocation of physical pages among processes, and must close files when processes exit, for example.
| Next | ||
| Nachos Machine |