Compile method frame detection method and device code...

Details Compile method frame detection method and device code... Compile method frame detection method and device code...

1999-06-30

2004-05-11

Zhen, Wei Y. (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S151000

Reexamination Certificate

active

06735761

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to a compiler, and more particularly to a Java (Trademark of Sun Microsystems Corp.) JIT (Just In Time) compiler.
BACKGROUND ART
Currently, Java is positioned for use not only as a common language of network computing, but also as a standard, object-oriented and platform-independent language. A program written in Java is compiled to produce a program in bytecode that can be executed by a Java virtual machine. This affords to a program written in Java the advantage that it can be run by any computer that supports Java, regardless of the CPU employed (multi-platform capability).
However, the execution of the bytecode by the virtual machine provides a performance that is inferior to that provided by the direct execution of a code that is written in a machine language. In general, therefore, while a Java program is executed, a JIT compiler converts the bytecode into a machine language code (a code that is hereinafter referred to as a JITed code), and the JITed code is executed instead of the bytecode. The minimum unit for the compile is a sub-routine called a method. By converting into the machine language code a code which is frequently executed, the performance characteristics of the machine language code are exhibited, while at the same time the multi-platform characteristic of the Java bytecode is retained.
Since the JITed code of the method is adequate for a CPU that executes a program, it is the equivalent of the optimal code generated by a C compiler, for instance. In a CPU that currently be in use, when a sub routine is called, in a stack, the sub-routine forms an area, which is called a frame, for the storage of local variables that are used by the sub-routine.
FIG. 1
shows a stack after a sub-routine A has called a sub-routine B and the sub-routine B has called a sub-routine C. The stack has been extended upward, the individual areas constituting the frames of the sub-routines, while a stack pointer SP points to the topmost address in frame C. When the sub-routine C then calls a sub-routine D, a frame of the sub-routine D is formed on the current position pointed by the stack pointer SP. The stack pointer SP points to the topmost address in the newly formed frame. When returning from a certain sub-routine to the previous sub-routine, the frame for the certain sub-routine is removed. Thus, when returning form the sub-routine D to the sub-routine C, the frame of the sub-routine D is removed before the returning, and the address pointed by the stack pointer SP is returned to the one pointed at when the sub-routine C called the sub-routine D. In Java, a CPU resource is assigned for each unit execution, called a thread, and for each thread there is an inherent stack called a thread stack. The JITed code forms the previously mentioned frame (hereinafter referred to as a JITed frame) in the thread stack.
JITed frames are not the only ones found in the thread stack. JITed code may call a variety of service routines that a Java virtual machine provides, and some service routines may activate other, new Java virtual machines.
FIG. 2
shows the state where frames of JITed code and frames of codes other that JITed code coexist in a thread stack. The frames identified by alphabetical characters are JITed frames.
The use of memory by a JIT compiler will now be explained. A JIT compiler uses memory for the storage of JITed code or for a compiling work area. However, the memory that is available is not infinite. In particular, a computer having no hard disk has no virtual memory by the secondary storage; such a computer has only real memory, and memory having only a limited capacity can be provided for the use of a JIT compiler. The use of such computers that have only real storage has spread because of the introduction of an NC (Network Computing) machine. The NC machine was proposed as a countermeasure to provide a reduction in the operating costs associated with the client management side in a server-client environment. Since application programs can be downloaded from the server, one of these computers has no need for a hard disk, and is available at a low price.
When only a limited amount of memory is available for a JIT compiler, while such a JIT compiler is in use a shortage of memory may occur. In such a case, one of three countermeasures can be selected: (1) the JIT compiler does not compile the pertinent method; (2) the optimization level of the JIT compiler is reduced and the JIT compiler switches its mode into one that uses less memory; or (3) the JIT compiler gets new free memory space. In this invention, (3) is employed. To get free memory, a part or all of the JITed codes which have already existed and which can be discarded is discarded to release areas in which the discarded JITed code previously occupied. This is a concept that was already known at the time the SmallTalk system was developed, but no method has been provided that can be applied for a frame optimized-by a JIT compiler that is as good as the one available for the C language.
Only JITed code is discarded, and the discarding process is called JIT code garbage collection (GC). An active method for a thread being executed is recorded in the current context of the thread (a copy of a CPU resource, such as a program counter and a stack pointer), or in a JITed code frame that is held in the thread stack. If the JITed code for an active method is discarded, the relevant thread can not be executed. Therefore, only non-active JITed code is to be discarded. Since all the methods for which JITed code is provided are managed, only the JITed code for non-active methods is discarded, while active methods are maintained.
A method for finding active methods, i.e., a method for finding JITed frames in a thread stack, will now be focused on. As shown in
FIG. 2
, JITed frames and other frames coexist in a thread stack.
Although the efficiency of search for JITed frames is low, a conservative garbage collection method (hereinafter referred to as a conservative GC method) can be employed while no overhead is imposed on the performance of JITed code (see FIG.
3
). Specifically, all the effective areas in the thread stack are scanned, and all the values held in the thread stack are examined to determine whether they are addresses of JITed codes belonging to a specific method. If the addresses are of JITed code for a specific method, the method is regarded as active. If a JITed frame, including a pointer to JITed code, is present in the thread stack, the conservative GC method can find it. However, the conservative GC method has certain shortcomings: false JITed code addresses are extracted, and the discovery efficiency is low. Since all values in a stack are examined when the conservative GC method is used, if a JITed code address is unexpectedly included in the stack, it will mistakenly be identified as a real JITed code address. This gives rise to the shortcoming concerning false JITed code addresses. The reason the discovery efficiency is low will become apparent from the following. During the actual application of a program, the stack area tends to be large, and very many values, which are held in the thread stack, must be examined to determine whether it is the JITed code address of a specific method. In addition, the cost involved in obtaining a corresponding method from arbitrary values that are examined by scanning is high. Even if JITed codes are sorted according to the addresses in memory to which the JITed codes are assigned, the cost of extracting a method from JITed code addresses which are of several thousand, or of several tens of thousands, of JITed codes that are dynamically generated (or erased) will be very high. In addition to this, the period during which a program is halted due to the compiling process performed by a JIT compiler must be shortened as much as possible.
SUMMARY OF THE INVENTION
It is one object of the present invention to detect only JITed frames in an environment, in which the memory available to a JIT compiler is limited, and a JITe

Affiliated with

Also associated with

Rating

Compile method frame detection method and device code... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Compile method frame detection method and device code..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Compile method frame detection method and device code... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3205695