Introduction
A Virtual Machine Monitor, or hypervisor, e.g. Xen, manages the
concurrent execution of several guest virtual machines
(e,.g. operating systems) on a single computer. Hypervisors may
provide complete hardware virtualization, enabling unmodified
operating systems to be executed, or para-virtualization where
a standard hardware abstraction is presented via a software API,
which requires an operating system to be ported. Para-virtualization arose
in part because of difficulties in virtualizing the x86 hardware
platform, which is being addressed in more recent processors, but also
offers a much simpler route to porting other virtual machines, e.g., a
Java Virtual Machine, than a port to the bare hardware.
Para-virtualization in particular enables innovation in virtual
machine design because it significantly lowers the barrier to
entry. For example, rather than dealing with the wide variety of
hardware devices, e.g. network interfaces, a virtual machine need only
deal with the i/o abstractions provided by the para-virtualization
API. Furthermore, since a machine may run a standard guest OS
concurrently with the virtual machine, it is even possible to
completely offload certain tasks, e.g. file I/O, to a sibling guest
OS.
Hypervisors are fast becoming widespread and are expected to be
used routinely in the future as processors transition to
multi-core architectures that are capable of supporting many
concurrently executing systems.
Java Guests
We define a Java guest to be an implementation of a Java Virtual
Machine (JVM) that runs directly on the hypervisor para-virtualization
API, i.e., without the traditional operating system layer.
Many commercial environments today run application suites that are
entirely implemented in Java, or in languages that compile to Java
bytecode. Many of the other non-Java processes are related to
network management that could be abstracted into the guest or
a sibling OS. There are opportunities for both
simplification and performance improvement in a guest that is tailored
to a Java-centric application mix. We can identify three main
opportunities for improvement:
- Exploit access to low-level features: The Java platform APIs subsume the
traditional OS APIs in the areas of threads and memory management. The ability to
create custom thread schedulers and have efficient access to low-level memory management
operations may improve application performance.
- Specialization and optimization: A general-purpose
OS attempts to serve multiple constituencies and therefore contains code that is
not exercised by a given application.
Further, if the JVM and associated platform are
written in Java, there is an opportunity to dynamically optimize the
complete software stack from the application down to hypervisor API.
Possible benefits include constructing
optimal, pre-configured, application software stacks either through
the hypervisor checkpoint mechanism and/or ahead of time compilation.
- Simplified administration: By removing the operating system layer
we also remove any associated configuration and scripting, allowing
all adminstration to occur at the Java platform level.
- Increased platform developer productivity: The Guest VM software stack is
considerably simpler than the equivalent layered stack, and can be developed using a
modern integrated development environment, with the attendant productivity improvements.
Porting a traditional JVM, e.g. Hotspot, to Xen could realize some of
these benefits and, indeed, both BEA (Oracle) and IBM have similar projects
underway. The Guest VM project is taking a more forward looking
approach by building on the Maxine virtual
machine, that is entirely written in Java. This allows the
optimization opportunity to be fully exploited, which we believe has
significant potential.
What's New
The latest release is 0.2.1, see here for details.
Getting the Source Code
Guest VM is open source software, licensed under the GPL version 2.0.
There are three independent components to the Guest VM source code:
- Maxine: The Maxine Virtual Machine
- GUK: The Guest VM microkernel
- GuestVM: Guest VM itself
Each of these is stored in its own Mercurial repository. Since Maxine evolves independently
from GUK and Guest VM, the latest version of Maxine might be incompatible with Guest VM.
Therefore when pulling Maxine, it is important to pull the version specified in the
instructions below. Each component should be installed in a subdirectory of the same
parent directory in order for the build process to work properly.
Documentation
Slides and Talks
Team Members
Staff
- Mick Jordan, Principal Investigator, Senior Staff Engineer
Interns
