Data Structure Using in Our Dynamic Code Optimization

In this section, the data structure using dynamic code optimization is given. These include the data arrangement in the external memory, method cache and each of the runtime data structure.

i. Data Arrangement in the External Memory

The application programs are compiled into Java class files by the Java compiler (javac), with all the linked library programs recompiled, and then passed to JavaCodeCompact (JCC).

In conventional class loading, javac is used to compile Java source files into Java class files, which are loaded into a Java system, either individually, or as part of a jar archive file. Upon demand, the class loading mechanisms resolve references to other class definitions. JCC provides an alternative means of program linking and symbol resolution. First the multiple input class files will be combined, and JCC will determine the layout and size of an object instance.

Only the designated class members will be loaded and linked with the Java Virtual Machine in order to reduce JVM’s bandwidth and memory requirements.

Resolution of symbols is also performed in this stage, which reduces the start-up time of JVM.

The output of JCC is a C file and its format can be arranged by the user-defined writer. In JOP system, the writer is redesigned to have JCC output a data layout file like the data arrangement in the external memory (SRAM in Spartan-3) and loaded it

directly to the external memory. An illustration of it is shown in Fig. 28.

All Method’s: Bytecode

Special Pointer String Table

All Classes

Static Fields Class Information

Method Table :

(a method use 2 address)

Constant Pool Interface Table Address of Special Pointer

0

1

Fig. 28.Data Arrangement in the External Memory

All of data in this output file are united in 32 bits of an address. This means that the address 0 has 32 bits data, and the 33rd bit is the first bit in address 1. After collected all the designated method bytecodes, JCC has the bytecode size in 32-bits. The JOPWriter writes this size added one in the first address, and then all the designated method bytecodes. Finished all the writing of bytecodes, the next writing address must be the data saved in address 0, because it is the size of bytecodes added one.

Then we save four special pointers: a pointer to boot code, a pointer to first non-object method structure of class JVM, a pointer to first non-object method structure of class JVMHelp, and a pointer to main method structure. We can easily get special pointers by using the data in address 0, because it is also the address of first special pointer. For example, the data in address 0 adds three is the address of main method

structure.

The next area is the string table area, followed by the all-class data area. The all-class data area contains the static fields, class information, method table, constant pool, and interface table if this class has interfaces. In this area, the data related to all the classes are listed one after another.

All of the information in the output file (the same as in external memory) will be used while execution. The method table (Fig.

29) of a class is the key data structure to get the address to other class information. Note that a method table occupies two address spaces, and an address is 32 bits.

Local Count Constant Pool

Start Address

22 27

0 31

Method Length

Arg. Count

Fig. 29.Method Table Structure

The highest 10 bits in the first address of method table are the length of method bytecodes with 32 bits a unit. By shifting right 10 bits of the first address we can get the method bytecodes’ start address that points to the second block in Fig. 28. The start address has 22 bits and it is in Big-Endian byte order. The second address stores the constant pool pointer in 22 bits, the number of local variables in 5 bits, and the number of arguments in 5 bits.

ii. Method Cache

Method cache is also called bytecode cache. Because the fetch of external memory is very expensive, the concept of method cache is created in JOP. During one external memory fetch, the whole bytecodes of one executing method are fetched and loaded to

the method cache, which is usually a memory area synthesized on FPGA. The external memory fetch time can be smaller than fetching one address a time. For example, assume that we fetch one address in external memory takes 3 microseconds.

We will spend 30 microseconds if we want to fetch a method with 10 units (32 bits a unit) address bytecodes. However, if we fetch all bytecodes of that method ( 10 units address) one time, we may just spend 22 microseconds in fetching external memory.

Method cache is designed to cache just one method bytecodes. Consider this example program [14]:

Foo () { A();

B();

}

We will have the following cache loads:

1. method Foo is loaded on invocation of Foo()

2. method A is loaded on invocation of A() 3. method Foo is loaded on return from A() 4. method B is loaded on invocation of B() 5. method foo is loaded on return from B()

It should refill the method after returned from its internal method. This is the main drawback of the method cache. But by that we can almost make sure that the method cache will reload when executing the same method next time. As a result, we do not need to reflash the method table when we modified the executing method bytecodes in our dynamic code optimization scheme. This also saves much time in doing

optimization.

iii. Runtime Data Structure

As we mentioned before, memory is addressed as 32 bits data, so the memory pointers are incremented for every four bytes.

No single or 16 bits access is necessary in our JOP system. The reference data type is a point to memory that represents the object or an array, which is pushed on the stack before an instruction operating on it. A null reference is represented by the value 0 [14].

In the following we are going to see each runtime data structure.

a. Stack Frame

First we look into the stack frame. On a method invocation, the information of the invoker is saved in a newly allocated frame on the stack. It is restored when the method returns. The information consists of five registers: SP (Stack Pointer), PC (Program Counter), VP (Variable Pointer), CP (Constant Pool Pointer), and MP (Method Table Pointer).

SP, PC and VP are registers in JOP while CP and MP are local variables of JVM.

Fig. 30 (see [14]) provides an example of the stack change before and after invoking a method. The caller has two arguments and the called method has two local variables.

The arguments that we want to pass into the invocated method can be accessed in the same way as local variables. As in this example, the arguments arg_0 and arg_1 will become var_0 and var_1 with the original var_0 and var_1 shifted to var_2 and var_3. The start address of the frame can be calculated with the information from the method table:

Frame address = VP + Arg. Count + Local

Count

Fig. 30. Stack Change on Method Invocation

b. Data layout

In JOP, objects are stored in memory during runtime in the Fig. 31 (see [14]) format. Note that the object reference points directly to the first reference of the object to speedup. We can access the class information pointer by object reference subtracted one.

Class Method Pointer Instance Variable 1 Instance Variable 2

…

Instance Variable n Object

Reference

Fig. 31. Object Format

The array layout in memory is just like an object. We showed the array format in Fig. 32 (see [14]). Also, if we want to access the array length, just take object reference subtracted one.

Fig. 32. Array Format

c. Runtime Class Structure The runtime class structure of JOP is shown in Fig. 33 which had discussed in i as allclasses’information.Thisclassstructure is stored in the external memory. For indicating the pointers in previous data structure, we drew this class structure again with pointers Class Reference, Class Method Pointer, MP, and CP.

Class Variable 1 Class Variable 2

…

Instance Size Interface Table Method Structure 0 Method Structure 1

…

Class Reference Constant Pool Length Constant 1

Constant 2

…

Interface Reference 0 Interface Reference 1

… Class Reference

Class Method Pointer

Current Method (MP)

Constant Pool (CP)

Fig. 33. Runtime Class Structure

3.2 The Proposed Dynamic Code