Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2000-01-28
2003-12-30
Nguyen-Ba, Anthony (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S108000, C717S116000, C717S148000
Reexamination Certificate
active
06671877
ABSTRACT:
DETAILED DESCRIPTION OF THE INVENTION
1. Field of the Invention
The present invention relates to a method for calculating an activity degree of a method in order to effectively select a method for discarding a code.
2. Background of the Invention
Presently, Java™ is widely used not only as a common language for network computing but also as a standard object-oriented language not dependent on any platform. A program written in Java™ is translated into a bytecode which is executed by a Java™ virtual machine. Accordingly, a program once written in Java™ has an advantage that it operates on any computer supporting Java™ regardless of its CPU.
Despite execution of a bytecode by a virtual machine is inferior to direct execution of a machine language code in terms of execution performance. Thus, in general, the bytecode is translated into a machine language code (hereafter referred to as “JITed code”) by a JIT compiler during operation of a Java™ program as to execute a JITed code instead of a bytecode. The minimum unit of compilation is a subroutine called a method. A frequently executed code is translated into a machine language so that performance of a machine language code may be exploited while preserving multi-platform characteristics of a Java™ bytecode.
A JITed code for a method is equal to an optimization code generated by a C compiler and so on on the point of being a code suited to a CPU on which a program operates. In general, in the currently popular CPUs, if a subroutine is invoked, the subroutine forms a stack of an area (referred to as a “frame”) for storing a local variable to be used by itself.
FIG. 1
shows a state of a stack when subroutine A has invoked subroutine B and subroutine B has invoked subroutine C. In this drawing, the stack extends upward. The areas represent respective frames of the subroutines. When returning from each subroutine, its frame is removed. In the case of Java™, CPU resources are allocated to each executable unit called a thread which has its own stack (referred to as a “thread stack”). A JITed code creates the above-mentioned frame (hereafter referred to as “JITed frame”) on a thread stack.
While, in most cases, a method is initially executed by an interpreter, it is compiled by a JIT compiler if determined that it is executed more than a certain level in terms of execution frequency or execution time. Once generated, JITed codes are managed in memory. The time when a Java™ system assures that they can be safely discarded is when the Java™ system discards a class (hereafter “class unload”) by garbage collection (hereafter “GC”).
There are cases where, if the memory used by a JIT compiler including a JITed code is limited or to be limited, only class unload is not sufficient. For instance, in a desktop environment where operation is on a thin client without any virtual memory by a hard disk such as a network computing machine (hereafter an “NC machine”), memory limitation is a realistic problem. In such a desktop environment, multiple Java™ applications such as a mail, a word processor, and a scheduler are simultaneously activated and thousand of types of methods may be invoked, though a significant percentage of those methods are not present (are not active) in each thread stack. Since class unload only discards a class and its method with no possibility of being fully used in a Java™ system, a JITed code of such a nonactive method is not discarded. Thus, a JIT compiler has a mechanism of JITed code discarding.
In a current context (a program counter) or a stack pointer of a thread during execution and the like (copies of CPU resources) or a frame of a JITed code held in such a thread stack, an active method in the thread is recorded. If a JITed code of an active method is discarded, a thread cannot be executed. Accordingly, it is a nonactive JITed code that is discarded. The easiest way of discarding in JITed code discarding is to discard all nonactive JITed codes. However, this method is wasteful since more than necessary JITed codes are discarded. Since optimizing compilation of a method takes time, they should be selectively discarded under a policy of “a method to be promptly executed is not discarded.” As an example of an effect of accurate selection, it is assumed that there are method A wherein JITed code discarding is performed now and immediately executed and method B wherein it is executed then minutes later. If A is discarded, the amount of memory of a JITed code of A which was just discarded and the amount of memory necessary for compilation work of A must be immediately secured. On the other hand, if B is discarded, the amount of memory of a JITed code of B becomes available memory for ten minutes. In reality, multiple JITed codes equal to the necessary amount of free memory are discarded. While an ideal policy of discarding is to discard JITed codes to be no longer used, such information is normally unavailable. It is more realistic to infer it and discard them in order of the least recently used method. Hereafter, it is called the JITed code discarding policy.
There are execution frequency (how many times it was called) and execution time (the time a program counter was pointing the method) among normally thinkable profiles of a method. Collection of execution frequency is performed by increasing a counter of a method every time the method is called. If the method is compiled by a JIT compiler, updating of execution frequency measured by an interpreter until then is terminated, so execution frequency information for a JITed code cannot be obtained from the interpreter. To obtain execution frequency information for a JITed code, it is necessary to count execution times at a prologue of a JITed code of each method. For instance, on a x86 platform, inc dword ptr [counter address] instruction is added. Collection of execution time is performed by interrupting (typically timer interruption, or executable instructions interruption depending on a processor) at regular intervals and collecting program counters (hereafter “pc”).
If these conventional profiles are used as a JITed code discarding policy, a problem arises. First, as to execution frequency, it is a problem to refer to memory and count it each time a JITed code of each method is executed because it causes overhead to a state where memory is not exhausted. Moreover, there is a possibility of mistakenly discarding a method with low frequency but to be immediately called. Since what is necessary is a JITed code occupying memory without being called, it is beside the object. Also, as to execution time, interruption and management of collected pc (cost of association if immediately associated, or retention if not) are problematic because they cause overhead to a state where memory is not exhausted. In addition, similar to the case of collecting execution frequency, there is a possibility of mistakenly discarding a method with short execution time but to be immediately called.
As mentioned above, it is irrelevant to adopt a conventional profile method as a JITed code discarding policy, and it may cause an inadequate JITed code discarding. An object of the present invention is to provide a method for calculating an activity degree of a method representing how readily it can be performed in order to effectively select a method for discarding a code.
SUMMARY OF THE INVENTION
To attain the above object, at a compilation time, the present invention generates and stores into a storage a calling map concerning a method call which may happen in a method, and generates and stores into a storage a code for recording a method call which is actually issued. This calling map is organized, for a certain address in a method, to be suitable for outputting any method call which may happen from the address onward. However, it is also possible to output method calls for each method. Once compilation ends and a generated code is executed, a calling map concerning method calls which may happen in a method and information concerning method calls which are actually issued are recorded
International Business Machines - Corporation
Nguyen-Ba Anthony
Truelson Roy W.
LandOfFree
Method and device to calculate activity degrees of method... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device to calculate activity degrees of method..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device to calculate activity degrees of method... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3107512