Method and system of providing dynamic optimization information in a code interpretive runtime environment6412107Abstract The present invention is a code preparation system (12) which accepts input code (11) in intermediate code format, our source code format which is first translated into intermediate format, analyzes the intermediate code, then provides optimization information, hints, and/or directions (collectively referred to as "optimization information") for optimizing execution of the intermediate code by a code interpretive runtime environment, such as a Java Virtual Machine. The code interpretive runtime environment is operable to selectively implement the optimization information received from the code preparation system (12). The optimization information is provided to the code interpretive runtime environment in the form of additional attributes added to a class file (14) generated by the code preparation system (12). Processing in accordance with the received optimization information allows the code interpretive runtime environment to execute code more efficiently and to manage use of its resources more effectively, particularly when executing in a limited resource computing environment. Such limited resource computing environments include set-top boxes, digital personal assistants, etc. Claims What is claimed is: Description TECHNICAL FIELD OF THE INVENTION
COM.TexasInstruments.JIT {
u2 attribute_name_index;
u4 attritute_length; /* not including first 6-bytes */
u2 attributes_count;
attribute_info attributes[attributes_count];
}
The presence of this attribute in the class file 14 informs the Java runtime system to JIT compile the intermediate codes for the method that includes the "Code" attribute. In addition, the COM.TexasInstruments.JIT attribute is also used to pass optimization information generated by the code preparation system 12 or directions to the JIT compiler instructing it to perform its own optimizations at compile time, as discussed hereinabove. For these latter two cases, the extra information is passed as sub-attributes of the attribute COM.TexasInstruments.JIT. In its simplest form, the COM.TexasInstruments.JIT attribute informs the Java runtime system to JIT compile using its own default settings. In which case the attribute format is:
COM.TexasInstruments.JIT {
u2 attribute_name_index;
u4 attritute_length; /* 2 */
u2 attributes_count; /* 0 */
}
where there are no sub-attributes. Note that the sub-attribute "attribute_length" always has a value of two (2) in this case indicating the two bytes which follow for the sub-attribute "attributes_count" . The value of the sub-attribute "attributes_count" in this case is always zero (0). In a second example, additional optimization information may also be passed to the code interpretive runtime system by adding sub-attribute information to the compilation attribute. As in the first example, the compilation attribute informs the runtime system to JIT compile the intermediate code for the particular method. With the additional of sub-attribute information, it may also inform the JIT compiler to perform optimizations such as instruction scheduling and peephole optimizations on the native code that it generates. In this case, a sub-attribute, COM.TexasInstruments.JITOptimizations, is added to the COM.TexasInstruments.JIT attribute. This then gives us:
COM.TexasInstruments.JIT {
u2 attribute_name_index;
u4 attritute_length; /* 2 + size of */
/* COM.TexasInstruments.JITOptimizations
*/
u2 attributes_count; /* 1 */
attribute_info attributes[attributes_count];
/* COM.TexasInstruments.JITOptimizations
*/
}
where the attributes_count is 1 and the sub-attribute follows the count. The format of the COM.TexasInstruments.JITOptimizations attribute is:
COM.TexasInstruments.JITOptimizations {
u2 attribute_name_index;
u4 attritute_length; /* always 2 */
u2 optimization_mask;
}
Here the two byte unsigned integer field "optimization-mask" indicates which optimizations the JIT compiler is to perform. A predefined set of optimizations is established where each optimization is given a value, for example from 0-15. Setting a corresponding bit in the "optimization_mask" field informs the JIT compiler to perform that particular optimization. As an example, assume the following predefined set of optimizations:
instruction scheduling -0
loop alignment -1
peephole opts. -2
. . .
unused -15
To inform the JIT compiler that it should perform instruction scheduling and peephole optimizations, the "optimization_mask" field is set to 5 (i.e., 101 in binary). If more than sixteen (16) optimizations are available, the size of the optimization_mask is increased to more than the 2-bytes shown hereinabove. The code preparation system of the present invention provides developers with an interface that allows them to select these individual optimizations. In addition, the tool also provides a general interface which, for example, allows developers to invoke the JIT compiler at low, medium, or high optimization, or to select a pre-defined set of speed or space optimizations. However, under the floor, these field settings can still be transformed into the attribute COM.TexasInstruments.JITOptimizations as described hereinabove, where each of these more general levels of optimization performs zero or more of the individual optimizations described hereinabove. In other words, this more general interface is provided for convenience. Returning to FIG. 4, if, at decision block 44, the user does not choose to select processing options, operation continues at decision block 56 where the user may choose to perform optimization analysis on the input code 11. If selected, operation continues to block 58 where the code analyzer 36 is invoked to pre-process, i.e., pre-compile the input code. In one aspect of the invention, optimization information generated by the code preparation system 12 is provided to the JIT compiler, not shown, which is part of the code interpretive runtime environment and is operable to generate native code in accordance with this optimization information. The generation of the optimization information, which may require significant resources, i.e., in terms of both processing time and system memory, is performed ahead-of-time (AOT) by the code preparation system 12. The code preparation system 12 operates, relatively speaking, irrespective of time and in a computing environment which generally has more resources at its disposal than those available to the computing environment in which it is contemplated that the code interpretive runtime system operates. The JIT compiler, which operates in the contemplated limited resource environment of the code interpretive runtime system and whose execution speed is always critical to an application's performance, then uses this pre-computed optimization information to operate optimized native code. Therefore, the method of separating compilation in accordance with the present invention allows the JIT compiler to incorporate costly optimizations into its code generation process without actually incurring any of the resource-related expense that would otherwise be required if the separation was not done. This further allows the JIT compiler to continue operating within the stricter confinements imposed by its limited resource operating environment. Thus, in the following example, information about local variable register binding is passed to the JIT compiler. In this case, the code preparation system 12 analyzes the intermediate code using the code analyzer 36 and then passes the resulting optimization information to the JIT compiler. To pass the register binding information, the attribute COM.TexasInstruments.JITLocalBindings is passed as a sub-attribute of the attribute COM.TexasInstruments.JIT. This gives us:
COM.TexasInstruments.JIT {
u2 attribute_name_index;
u4 attribute_length; /* 2 + size of */
/*
COM.TexasInstruments.JITLocalBindings */
u2 attributes_count; /* 1 */
attribute_info attributes[attributes_count];
/*
COM.TexasInstruments.JITLocalBindings */
}
where the attributes_count is one (1) and the sub-attribute follows the count. The format of the COM.TexasInstruments.JITLocalBindings attribute is:
COM.TexasInstruments.JITLocalBindings {
u2 attribute_name_index;
u4 attribute_length; /* variable length */
u2 locals_count;
{
u1 segment; /* 0 - register binding */
/* 1 - stack binding */
u2 offset; /* register number if register class */
/* frame pointer or stack pointer */
/* offset if stack binding. */
u2 start_pc; /* bytecode pc where binding starts */
u2 end_pc; /* bytecode pc where binding ends */
} local_bindings_table[locals_count];
}
Here, the local_bindings_table includes an entry for each local variable. Other attributes that are used in a similar fashion include: COM.TexasInstruments.JITLoopInfo COM.TexasInstruments.JITCallsBelowInfo COM.TexasInstruments.JITTypeInfo etc. The COM.TexasInstruments.JITLoopInfo attribute defines for the code interpretive runtime system information relating to processing loops in the code. The information includes loop boundaries via intermediate code addresses, the nesting of a particular loop, whether or not the loop includes calls, and potentially, the kind of loop (i.e., is this an iterator loop). The loop boundary information is helpful in that the only other way to detect loops in intermediate code is with the aid of a flowgraph. The other information is useful in producing code that, for example, uses special overhead hardware loops which are available on most digital signal processing (DSP) chips. The COM.TexasInstruments.JITCallsBelowInfo attribute provides information to the code interpretive runtime system to indicate whether native code generated from the intermediate code will include calls. This information is then used, for example, to determine whether parameters passed in registers should be left in those registers for the duration of execution of the related routine. Typically, if there are calls made by the routine, answer is no in that the registers are needed to pass parameter information to the callee routines. The COM.TexasInstruments.JITCallsTypeInfo attribute provides information resulting from tracking class types of various variables and stack slots in the intermediate code. For example, tracking types provide information that indicates that the object associated with a `invokevirtual` (call virtual method) instruction is of type `MyClass`. Therefore, code is generated which directly calls the routine `MyClass` rather than code which calls a routine via a dispatch table. In addition, general information relating to local variables and stack slots in the intermediate code can also be provided. Information indicating, for example, that an object associated with a `getfield` instruction will never be NULL, therefore, bypass the null pointer check in the generated native code for this particular `getfield` instruction. Additionally, information indicating, for example, that an array object associated with an `iaload` (load integer from array) instruction is known to always have legal bounds for this particular `iaload`, therefor bypass the bounds check in the generated native code. Other optimization information passed includes a fully annotated flowgraph or common sub-expression information useful in cases where a certain object's fields or methods are repeatedly accessed or invoked. Note also that the given optimization information can be either target dependent or target independent and used to create one or more sets of optimization attributes. The code preparation system 12 also passes directions to the code interpretive runtime system in addition to passing optimization information. These directions are usually relating to optimizations that must be done on generated native code as opposed to being done on intermediate code. Thus, for example, directions can be given to the JIT compiler to perform instruction scheduling and peephole optimizations as described hereinabove in the description of the COM.TexasInstruments.JITOptimizations attribute. The following example shows how both optimizations and directions can be passed by the JIT.
COM.TexasInstruments.JIT {
u2 attribute_name_index;
u4 attribute_length; /* 2 + size of */
/*
COM.TexasInstruments.JITOptimizations + */
/*
COM.TexasInstruments.JITLocalBindings */
u2 attributes_count; /* 2 */
attribute_info attributes[attributes_count];
/*
COM.TexasInstruments.JITOptimizations */
/*
COM.TexasInstruments.JITLocalBindings */
}
The COM.TexasInstruments.JIT attribute thus includes both the COM.TexasInstruments.JITOptimizations sub-attribute and the COM.TexasInstruments.JITLocalBindings sub-attribute. Returning to decision block 56, if the user chooses not to perform AOT optimization analysis, operation continues at decision block 60 where the user has the option of providing alternate set or sets of intermediate code to the code interpretive runtime system. Note that some pre-analysis by the code analyzer 36 may be required to make the decision. If, at decision block 60, the option to provide alternate set or sets of intermediate code is selected, operation continues at block 62 where the code preparation system 12 generates the alternate intermediate code sets. Alternate sets of intermediate codes are generated, for example, for a given method where certain calls have been inlined, or similarly, an alternate set of intermediate code where certain loops in the method have been unrolled. Although the original intermediate code could itself be changed, by providing an alternate stream of intermediate code, the code interpretive runtime system is provided with the option of ignoring the alternate stream if, for example, resources are low. Once the alternate set or sets of intermediate code are generated at block 62, processing continues at decision block 63 where, if necessary, the code analyzer 36 is invoked at block 58 to analyze the alternate intermediate code. Otherwise, processing continues at block 48 where the associated attribute information is then generated. As an example, the attribute COM.TexasInstruments.AlternateCode is used to pass alternate set or sets of intermediate code to the interpreter of the code interpretive runtime system. This attribute is part of a method_info structure which is part of a class file (the same structure in which the predefined Code attribute is attached). The attribute is defined as follows: COM.TexasInstruments.AlternateCode { u2 relative_importance; . . . . . . same fields as predefined Code attribute . . . . . . } The relative_importance field specifies the importance of this method relative to the entire application. Using this value, the JVM then determines whether to use the alternate set or sets of intermediate code or to ignore them. The runtime system ignores the alternate set or sets of intermediate code if, for example, resources (mainly space in this case) are running low. Note that a single method info structure can include multiple COM.TexasInstruments.AlternateCode attributes. Also, note that this new attribute may also include the COM.TexasInstruments.JIT attribute (and hence any of its sub-attributes). This is beneficial in cases where the intermediate code is originally interpreted and then JIT compiled after too many interpretations. OTHER EMBODIMENTS Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||