We’ll now look at how all of this plays out in the implementation of the Java virtual machine on several popular platforms. In many ways, this is a section that we’d rather not have needed to write: Java is a platform-independent language, and to have to provide platform-specific details of its implementations certainly violates that precept. But we stress that there are very few times when these details actually matter.
On the other hand, one of the hallmarks of Java in the real world is that vendors of Java virtual machines are allowed to compete over the implementation of those virtual machines: which one is faster, which one can run more threads, and so on. As long as the implementation of the virtual machine follows the Java language specification and conforms to the Java Compatibility Kit for testing, then it is a valid Java virtual machine. Because of the flexibility that the specification allows for thread scheduling, all of the implementations we’ll discuss are certainly valid Java virtual machines (at least in the area of thread scheduling support).
The first model that we’ll look at is the simplest. In this model, the operating system doesn’t know anything about threads at all; it is up to the virtual machine to handle all the details of the threading API. From the perspective of the operating system, there is a single process and a single thread.
Each thread in this model is an abstraction within the virtual machine: ...