The goal of the project was to port the existing Java Fast Virtual Machine (FastVM) on the Alpha platform to IA-32. This includes the whole runtime environment as well as the just-in-time compiler. The work during the summer was mainly focused on the just-in-time compiler. The important parts of the project were to bridge the differences between the Alpha and IA-32 architecture and especially to design a fast and efficient register allocator on the IA-32 platform.

Apart from the general difference of processing 32 bit instead of 64 bit the Intel architecture complicates the implementation of the just-in-time compiler in various aspects:

• no fixed instruction length
• few multi-purpose registers
• floating-point stack instead of registers
• registers bound to certain instructions

Compared to the standard GNU stack frame specification, several things had to be changed for the Java just-in-time compiler. For example, since some values are represented as 64-bit values within Java the stack frame needs to be aligned to 8 byte boundaries instead of 4 byte boundaries. Furthermore, a stack check needs to be introduced in order to be able to do appropriate exception handling. Also, since it was the goal to make as many registers as possible available for general purpose a reserved stack slot is introduced to distinguish the parent from the current stack frame which makes the frame pointer redundant.

The floating-point unit in IA-32 uses a floating-point stack instead of directly accessible registers in order to store floating-point values. Floating-point operations can be executed either on the first two elements of the stack or on an element in memory and on top of the stack, whereas the result is stored on top of the stack. There are no transfers possible between the processor registers and the floating-point stack which can become a performance problem if the register allocator doesn't take it into account.

The design goal of the register allocator is to minimize the compile time, and optimize the generated code as much as possible. In total there are 7 registers available for general purpose values depending on whether the instructions are able to address these registers. In addition the floating-point stack can carry 7 floating-point values as well.
The register allocator for the Alpha version of the FastVM uses a data structure that assigns each entity in the program a home location and maps this to temporary locations in the registers. The register allocation itself works on a local scheme for each Java bytecode instruction and doesn't use any global algorithm since this can become expensive.

When comparing the ratio of the SpecINT and SpecJVM benchmarks of different JVM implementations on different platforms, the FastVM is one of the leading implementations. It is the question whether it is possible to preserve the performance of the implementation on a different platform. We compared the first prototype implementation of the FastVM for IA-32 to existing JVM implementations by Sun and IBM and found that on several of the SpecJVM benchmarks the FastVM is doing better by about 10%. However, there are still benchmarks that do a large number of floating-point operations, where performance is decreasing. This has to do with the complicated floating-point handling on IA-32. But after all, this project shows that the FastVM can be ported to a different architecture with a minimum amount of work in a few months.