Two-Level Runtime Image Design

As mentioned before, the runtime information of a method is loaded into the Java core before the method is executed. The runtime image contains all information for the Java core to execute a method, which includes the class symbol table and the method image. In our previous design, the whole class image is loaded as the runtime image to the Java core. The disadvantage of this approach is obvious since some method bytecodes that are not used would be loaded. In addition to being memory-inefficient, such class-based buffering system also makes it more complex to implement exception

handling and multi-threading due to lack of some method-based information. For the exception handling mechanism, the exception routines are a section of Java bytecodes in a method image. To be efficient to find such exception routine in a method when an exception happens, the information locating the method’s exception routines is needed.

Fig 8. Two-Level runtime image.

In the current design shown in Fig 8, the class images remain at the second-level memory space and each class image is divided into two parts: the class symbol table and the method images. The class symbol table contains reference pointers that are used in the mechanism of dynamic resolution. And the method images contain method’s instruction bytecodes and eight-byte headers. To execute a method in a class, the required data are only a class symbol table and a method image. Therefore, only the class symbol table and a method image are required to be loaded into the buffers to execute a method. The essential runtime image is called the method area containing a class symbol table and a method image, which is a subset of class image. To locate and identify each class symbol table and each method image in both the RISC side and the Java core side, a dedicated class ID is related to a class symbol table and a dedicated

Class Images Pool (DDR SDRAM)

method ID is related to a method image. In the process of loading the method area in the Java core, the class ID and method ID are used as indexes of lookup tables to retrieve information to locate class symbol table and method image. In addition the IDs also facilitate the design in exception handing to fast access the specific method or class information from lookup tables.

Fig 9. Method area format.

The format of the method area is shown in Fig 9. The method image contains eight bytes headers and the method instruction bytecodes. The header contains the access_flag, parameter_count, max_stack, and max_local. The access_flag indicates the method’s declared feature, such as PUBLIC, INTERFACE, ABSTRACT…etc. The parameter_count indicates the numbers of parameters with the invocation of this method. The max_stack is the maximum number of stack elements in the method runtime. And the max_local is the maximum number of local variables in the method runtime. The other two header items, parameter_count and max_local, are two keys to adjust the stack frame during method invocation

In the Java language behavior of method invocation, the top operands may be

local variables in the invoked method. In the implementation of the Java core, the process of changing stack frame to the invoked method’s stack frame are achieved by adjusting the stack pointer (SP) and variable pointer (VP). In the design of the Java stack, a typical method frame contains local variables, return frames (three stack elements that contain for return information) and operands. The SP points to the base address of the current method stack frame and the VP points to the top element in the current method stack frame.

Fig 10.Adjust the stack frame when invoking the method ‘A’ with the method image header entries: parameter_count and max_local.

An example of adjusting the stack frame in method invocation is shown in Fig 10.

When a method “A” is invoked, the method image of this method will firstly be loaded to the buffers in the Java core. Before executing the invoked method, the Java stack is allocated for the invoked method, which is achieved by adjusting the SP and VP. The new SP is adjusted to the value that the old VP minus the parameter count. And the new VP is adjusted to value that the new SP plus max_local and plus three for the return frames. After the process of adjusting the VP and SP, the parameters are placed at the local variables in invoked method stack frame, and the left local variables and

return frame are also allocated. In the end, the new stack frame for the invoked method is ready for method execution.

The other part of the method area, class symbol table contains reference data, as shown in Fig 10. For some instruction bytecodes, the operand followed by an operator bytecode is a constant pool index that references to the class symbol. If the referenced class symbol is CONSTANT_Fieldref_info type, CONSTANT_Methodref_info type, or CONSTANT_InterfaceMethodref_info type, the reference data will be a 32-bit table address indexing the class symbols location in the cross reference table. If the class symbol is CONSTANT_Class type, CONSTANT_String_info type, or CONSTANT_Integer_info type, the class symbol data is directly stored at the reference data.

For example, the bytecode “new” is followed by an index indicating which of the class should be instantiated. The index operand indexes to the class symbol table to retrieve the reference data which is the CONSTANT_Class type of class symbol. The reference data is a class ID that is used as an interrupt service routine argument to the software instantiate routine. In the instantiation routine, the object space is then allocated in the heap memory. After allocating the object space, the interrupt service routine signals the Java core with a data which is an object reference (the heap address pointer to the object space). Then the Java core pushes the object reference onto the Java stack accomplishing the bytecode “new”. Such process to result the reference data to the class symbols is performed by the dynamic resolution controller. The dynamic symbol resolution provides a faster way to access class symbols for bytecode execution.

The linking process from the class symbol table to the cross reference table is done by the software class parser. In the next section, the process to buffer the method area containing class symbol table and method image is discussed.