Architecture of the Method Area Manager

In the framework of two-level runtime image design, the first-level memory space is composed of two circular buffers buffering the method area. To buffer method area, the class symbol table and the method image are separately buffered into two circular buffers which have different block sizes. The class symbol table circular buffer (CSTCB) has 32 blocks and each bock is of 256 bytes. Another circular buffer, the method image circular buffer (MICB), has 64 blocks and each bock is 256 bytes. The circular buffers are designed to buffer the data in a FIFO manner. We choose to

implement the FIFO policy rather than other sophisticated replacement techniques (e.g., LRU) due to its simplicity. Furthermore, some studies show that the method-based FIFO caching policy has reasonable performance for Java applications [25][26]. Note that a CST and MI may occupy more than one block in circular buffers. Therefore, a register, CSTCB_Pointer, is used to point the start block occupied by the specific CST in the CSTCB. And a register, MICB_Pointer, is used to point the start block occupied by the specific MI in the MICB. With the CST_Pointer, the specific block in CSTCB can be selected and accessed by the dynamic resolution controller. With the MI_Pointer, the specific block in MICB can be selected and accessed by the bytecode execution engine.

Fig 13. Architecture of the method area manager.

As mentioned before, there are three situations (method invocations, the method returns and the exceptions) that the Java core may trigger the dynamic method loading.

Method Area

method inf o method image data

2nd-level

In these situations, an enable signal raised by other components in Java core will trigger the method area manager to perform dynamic method loading. When the enable signal is raised, two input signals, Request_Method_ID and Request_Class_ID, are valid in the inputs, which are shown in Fig 13. The register Class_ID indicates which of the class symbol table should be located and the register Method_ID indicates which of the method image should be located. After the required method area is ensured in the circular buffers, the manager raises a loading_done signal to notify the Java processor the process of dynamic method loading is finished.

To perform the process of dynamic method loading, the method image buffer manager relies on one controller and two similar sets of tables and registers, which is shown in Fig 13. One set is for cooperating with the CSTCB and another one is for cooperating with the MICB. These two sets of tables and registers have similar functional components and each set have three registers and two tables. In the set cooperating with CSTCB, three registers are Class_ID, CSTCB_Tail_Pointer and CSTCB_Pointer. The register Class_ID indicates which of the CST is loaded or ready to be loaded. The CSTCB_Tail_Pointer points to the last block that is ready to be allocated. The third register CSTCB_Pointer points to the first block that locates the request CST. In addition, the set contains two tables CSTCB allocation table and the class lookup table. The CSTCB allocation table records the class ID of CST that is allocated in blocks. The input of CSTCB allocation table is block pointer and the output is a class ID indicating that which of the CST occupies the block. Another table, the class lookup table, has the information of parsed class information and the start block pointer of CSTCB, which is discussed in section 3.5.1.

Fig 14. FSM in the method area controller.

The finite state machine in the method area controller controls the process of dynamic method loading, which is shown in Fig 14. In the state (1), the controller waits for the enable signal to activate the process of dynamic method loading, which is requested from the bytecode execution engine or the exception handling unit. When the enable signal is raised, another two signals, Request_Class_ID and Request_Method_ID, are valid and separately stored to the registers Class_ID and Method_ID. After the enable signal is raised, the control state moves to the next state, Get Block Ptrs. In this state, the registers Method_ID and Class_ID are updated to requested IDs and separately index the class lookup table and method lookup table.

After one cycle delay, the information of block pointers of CSTCB and MICB are valid

(4) Load

at the outputs of the two lookup tables in state (3) Check Block Ptrs. If the value of block pointer is equal to 0xFFFF, it represents that the requested data are not buffered and the controller will start to load the requested data from the second-level memory. If the value of the block pointer is not equal to 0xFFFF, it represents the requested data is buffered and the value is the base pointer of the requested data in the circular buffers.

According to the outputs of block pointers from the two lookup tables, the state (3) moves to one of three states (4) Load CST, (8) Load MI and, (13) Done. If the requested method image and class symbol table are already buffered, the state machine moves to the state (13) Done. If the class symbol table are not buffered, the state machine moves to the state (4) Load CST. If the class symbol table are buffered and the method image is not buffered, the state machine moves to the state (8) Load method image.

Before moving to the state (4) from state (3), the item block pointer (0xFFFF) in class lookup table is updated from the CSTCB_Tail_Pointer which points to the blocks that locates the newly loaded CST. In the same time, the register CSTCB_Pointer is also updated from the register CSTCB_Tail_Pointer so that it can select the allocated block which is ready to be loaded in following processes. In the next state (4), (5) and (6), they are mainly to load each one word data of the requested class symbol table.

The state (5) raises the external memory loading signal and waits for the 32-bits external loaded data from the bus. After the ACK signal is raised, the external loaded data is valid and is stored to the pointed circular block in state (6). The states (4) (5) and (6) continue the loading processes until the whole requested CST data is buffered.

In the states (4) (5) and (6), a requested loaded CST data may occupy more than one block in the CSTCB. In this case, the register CSTCB_Tail_Pointer will plus one to point to the allocated block. And if the newly loaded data overwrites the block that

contains another CST data in the circular buffer, the item block pointer of the overwritten CST in the class lookup table must be updated to 0xFFFF. To retrieve the overwritten Class_ID, it relies on the CSTCB allocation table which records the occupied class ID of each block in the circular buffer. The CSTCB allocation table is indexed by the CSTCB_Tail_Pointer so that the class ID indicating the overwrite CST data can be retrieved from the output signal overwrite_Class_ID. The overwrite_Class_ID re-index the class lookup table and update the block pointer to 0xFFFF indicating that this CST is not buffered.

After loading the requested CST to the CSTCB, the controller state is changed back to the state (3) Check Block Ptr. If the requested method image is not buffered, a series of loading process similar to loading class symbol table will be performed again.

In the end, the request CST and MI are ensure to be buffered in the CSTCB and MICB.

The controller state is changed to state (11) Done and the controller raises the done signal to notify the Java processor to resume execution.

Chapter 4. The Implementation of the