On BA Chapter 9 (JPC Emulator)

JPC is an x86 emulator written in pure java. Its greatest feature is abstracting away the underlying hardware and operating system. In other words x86 code is converted to Java byte code, which in turn is interpreted by the processor specific JVM. And since there is no native code in it, JPC can emulate all the standard components of an x86 PC while remaining entirely inside the browser. While this architecture provides great flexibility and means to isolate the software behind two independent verified security layers (Java Applet sandbox and JVM), designing the architecture was a rather difficult task.

Disregarding JPC’s biggest challenge, emulation speed (and how the JVM architects tackled java performance limitations to achieve speed), and also the obvious benefits of JPC that come from running virtual hardware in isolation, I think that JPC as a project has a great vision. I personally liked Bochs and Qemu for their support for debugging kernel code. For instance, Bochs can set breakpoints in any kind of software (even if it is compiled without debugging info!), and provides an additional "debugging out port" you can easily access from within your kernel code to print debug messages. Qemu also can be configured to listen for a "gdb connection" before it starts executing any code to debug it. And those who spent sleepless nights trying to debug a kernel oops would greatly appreciate these features.

However, I think JVM’s vision is far beyond just being another emulator. Host platform and OS independency, the ability to run a virtual machine over the Web are great achievements. One can have its hard drive reside on his own server on the Internet, and access it from anywhere in the world by loading a local JVM and pointing it to the server. Furthermore, the core emulation task can be carried out on a remote server. While having the screen output and user input pushed via the Internet to the virtual machine owner we can imagine a model where there is no one to one mapping from user to virtual machine. We can model this as N users using M virtual machines. With this concept, if a machine is idle, any one of the users can use it, remotely launching a JPC image to work on their personal disk image data. This mostly fits users who use larger batch farms to run massively parallel tasks, such as rendering frames, optimizations, etc.

With cloud computing becoming more popular, JPC designers wonder why not use the millions of idle desktop computers worldwide instead and save the financial and environmental costs of using a datacentre. Old issues associated with cloud computing are easily overcome by JPC’s architecture. Gaining the trust of potential computing power donors would no longer be an issue as JPC provides a very secure approach. The cost associated with downloading, installing, maintaining foreign software is always a significant problem for the donor and/or system admin, but this is again no issue because all these tasks will be confined to the boundaries of the virtual machine. Last but not least, the available hardware and operating system provided by the donors will most likely be heterogeneous, but this again is not issue for JVM.

However, the road to creating an emulator hardware and OS independent, without compromising the requirement for maximum performance, was hard. In order to harness the complexity of the IA-32 architecture, the JPC designers had to come up with a clear and modular design and at the same time exploit all the little performance tips associated with the java language. I particularly liked a phrase where the authors catch the real measure of designing and implementing an emulator as opposed to designing hypervisors. During the design of JPC, they felt like they became “as schizophrenic as the codebase was”. And that was because ultimately, not having access to the memory or processor systems, called for different design decisions, that aimed for code clarity and modular design. While working within the processor and memory system, the design usually aims for ultimate performance, so breaking modularity or isolation between layers is often a good design choice.