Split machine

The physical layer is encapsulated in the inter process communication, ipc, interface. It consists of methods to open and close a channel between the converter and the interpreter. It also defines how to read and write bytes to an opened channel. On top of the physical interface, the converter utilises a command interface to send instructions to the interpreter, for example, load a class, and start executing a program. This command interface is called com in the figure.

2.4.1 Interfaces and modules of the split machine

The interfaces and modules introduced by the split machine concern com-munication between the interpreter and the class loader. The interpreter is extended with a linker to incorporate the classes sent from the class loader into the runtime data structures of the interpreter. At the same time, the class loader is extended with an IVM control module that sends commands and objects to the IVM node. Figure 2.16 shows the communi-cation layers:

Inter process commu-nication

ipc Command

protocol

Linker

com com

Figure 2.15 The overall structure of the Java Virtual Machine shows the main modules and interfaces. The greyed interfaces and modules are related to the split machine. Two separate memory areas are needed for the class loader and the interpreter respectively. Objects and commands are sent via the com interface to the IVM. The command module utilises basic methods in an under-lying physical interface, ipc, to send and receives bytes.

Resolver

class files

Class loader Interpreter

Heap Method area

Native method stack

Runtime constant pool JVM stacks IVM frame

Verifier Optimiser Real-time analyser Initialiser

Scheduler

file

garbage collector interface Garbage

collector

platform specific methods native methods

thread

thread &

monitor methods

portnative

Heap Method area Native method stack

JVM stacks IVM frame

transport classfile com interface command module

ipc interface interprocess communication module

physical

IVM control Linker

Figure 2.16 The different layers of the communication between the IVM and the class loader are designed to support different implementations.

The extra modules in the split IVM are as follows:

Inter process communication — a transport layer of bytes between communicates between the interpreter and the class loader.

Command protocol — defines commands and the representation of the transport classfile.

Ivm control — sends commands and objects to the IVM node.

Linker — implements the commands defined in command protocol.

The extra interfaces in the split IVM are:

Com — the command protocol transfers commands and objects to and from the IVM.

Ipc —the inter process communication encapsulates the physical transport layer. It contains methods to open and close channels, as well as methods to send and receive bytes.

The com interface describes object serialisation between the converter and the interpreter. It also describes control signals. The command mod-ule implements the com interface and the underlying physical transport layer is encapsulated in the ipc interface.

The linker module has to be added to the IVM. It converts the loaded objects into runtime objects, by resolving the pointer references to real references. The class loader sends and receives commands to the IVM via the IVM control module.

The transport classfile layer consists of the internal runtime data structures. However, the references have to be recalculated in the inter-preter if a separate memory area is utilised.

Initialisation of the IVM node’s internal data structures

Classes are sent in a transport representation. All references have to be recalculated in the IVM. It is essential to install the referred objects before reference recalculation is performed. The internal hierarchical template structure can also be sent to reduce the size of the interpreter.

2.4.2 Memory model

There are two alternative solutions to the split machine memory design.

The class loader memory area should be shared amongst the nodes to save space on the supervisor computer. The other alternative is more memory consumptive where a separate heap is allocated for every node.

The advantage of such a solution is to avoid irrelevant classes to reserve memory in the interpreter memory area. A combination of both ideas is also an alternative. The common classes defined in the API are the same for every interpreter node.

2.4.3 IVM references

There are two different ways to refer to an object and there are two differ-ent ways to refer to elemdiffer-ents in an object. The object may be accessed directly by a pointer, or via a reference. The pointer is only utilised by the garbage collector. Java objects and internal data structures are referred to

via references. The reference implementation is dependent on the GC algorithm. It may be implemented as a pointer or as an indirect pointer, i.e. a pointer pointer. Elements inside an object are accessed as offsets from the object pointer. Array elements are to be accessed via indices, or as offsets.

For instance, an object accesses its class by directly referring to its template. A class is referred from the bytecode by an index to it. The index is utilised in the global class template table to access the class. Index ref-erences are also utilised by Java arrays. The global class template table could be accessed from Java, if a reference to it is provided to the pro-gram. Figure 2.17 describes the different reference types.

The utilisation of indices is more secure than that of offsets. If the index reaches outside the array, an exception is thrown. Offsets do not have this feature.