Meta virtual machine

A meta virtual machine, MTM, describes and generates virtual machines.

There are many different requirements for different platforms. In the IVM, the port specific information is collected in a module that is modified

according to the specific platform. However, there always arise new demands and desires that are not thought of in the original design. It is desirable to test and evaluate new ideas quickly. For example, object lay-out could implement four-byte aligned data, which is desirable in 32-bits architectures, or one-byte aligned attributes in 8-bits processors.

New ideas could be implemented and tested without thorough knowl-edge of the virtual machine code. A future project idea is to implement a meta virtual machine and use Java as the description language (see [JIJ98]). To further describe the machine in a more expressive way is to utilise a symbol language, e.g. the notation language described in [Ive98.3]. This section discusses and presents design ideas for a MVM implementation in Java.

7.6.1 Template and class structure

It is essential to describe the internal structure of the JVM. This could be done in MVM as Java classes. The internal data structures that have to be described are the template structure of the IVM. It consists of:

• Classes

• Arrays

• Interfaces

• Primitive classes

• Instances of classes, arrays, interfaces, and primitive classes

• Methods

• Method activations (or instances)

The layout of the classes in the generated machine should be described by classes in the MVM. The attributes in a class of a generated machine should be described as attributes in the MVM.

7.6.2 Object layout

The object layout of a virtual machine should depend on the underlying processor architecture. In addition, different requirements such as mem-ory utilisation, performance, and hardware considerations, e.g. mapping of an object to hardware port, may affect the object layout. The MVM could describe the different object layouts in an object-oriented fashion.

Figure 7.1 describes three different object layouts: objects with four-bytes aligned attributes, one-byte packed attributes, and an object layout that maps a hardware port. To map a hardware port directly may avoid trans-lation overhead, as data in one representation must be converted to data that suits another representation. For example, an IP-packet may be mapped directly onto a Java object.

Some processors utilise different reference sizes, e.g. 16-bits references or 24-bits references. If the address space is four-bytes aligned, there is only need for 14-bits to fully cover a 16-bits address space. Reference sizes

should be reflected in the object layout. In Figure 7.1, 2-bytes and 4-bytes references are also taken into consideration.

Other requirements may also influence the object design. In a system with a small memory, a non-moving garbage collector could be considered, even if it results in fragmentation. An object consists of an object head, e.g. GC-information, a template reference, and synchronisation informa-tion. If the memory is limited to 256 memory blocks, a reference could be expressed with only one byte. In those systems, an object head could con-sist of three bytes: template reference, GC-information, and synchronisa-tion informasynchronisa-tion, e.g. an index to a monitor pool, or a direct reference to a monitor object. If the block size is four bytes, the remaining byte could be an attribute of reference type, a boolean type, or a byte type. The complete memory area would then be 1kb. A more realistic block size would be eight bytes, resulting in a 2kb heap. The VM could be equipped with a minimal interpreter optimised for an address space covered by 8-bit addresses. Drastic modifications like the minimal object design could be performed with the MVM. The effects could directly be compared with other alternative object designs.

7.6.3 Code generation

The MVM could be designed to generate C code for those segments that would benefit from faster execution. Primarily, the MVM could be exe-cuted as a Java program. However, a minimal amount of C code genera-tion from the MVM code is necessary to bootstrap the generated virtual machines. As the core code for the virtual machine is generated, the rest could execute as bytecodes. One advantage of a two-language representa-tion of the same descriprepresenta-tion is that a comparison would reveal bottle-necks.

IOPort 2 bits byte d 16 bits short c 14 bits byte e

Figure 7.1 Different object designs would easily be expressed in the meta vir-tual machine. The figure contains three different object designs. The variants are: four-bytes alignment, one-byte alignment, and hardware specific consider-ations.

a b p i

a b p i c q d e

internal fragmentation 4-bytes alignment, 4-bytes references

1-byte alignment, 2-bytes references

a p i

1-byte alignment, 2-bytes references, hardware port mapping

a p i c

b

db a c p i e q

b q d e

A short a byte b A p int i

B short c B q byte d byte e

IOPort

The generation of the core VM code could also be expressed in the MVM by adding descriptions of the code generation of the core. In the gen-erated VM, the interpreter’s bytecodes could be specially designed for a specific instruction set, e.g. a limited address space, or a digital signal processor. Different interpretation algorithms could be expressed without too much work. Optimisations, such as inlining, could be added. Virtual machines could easily be generated and compared. Another code genera-tion example is how the interpreter should be expressed in C code. One direct approach is to implement the interpreter as a switch statement, where each case alternative corresponds to a bytecode. There exist more efficient interpretation methods, e.g. by storing addresses as bytecodes, where the bytecode is implemented as a code sequence and located by a simple jump-instruction (the bytecode).

Another code generation consideration is to map the stack and the local variables on processor registers to increase performance. Bytecodes have been mapped to registers in a JIT compiler (see [ACL98]).

The interface to the code generation should be interesting to general-ise. The design of an interface that accommodates the different require-ments is an interesting problem.

7.6.4 Summary

A Java virtual machine generator could be a solution to test and compare the different requirements and optimisations that has emerged during the development of the IVM. Platform specific requirements could be obliged in a safer and more controlled way. A test suite could generate comparison tests of the generated machines. To raise the abstraction layer from the current C-code of the IVM to Java would result in code that is more secure and reduce the debugging time significantly. Most of the debugging sessions of the IVM revolve around errors in the hand coded garbage collector interface.

The interface to the machine description should be open and suffi-ciently simple to implement modifications. The meta virtual machine addresses these problems.