Abstract: A method, system, and program product for optimizing compilation. In the preferred embodiment, a compiler compiles a source-code file twice; once to gather register-pressure data, and a second time to apply the data. Thus, the compiler saves register-pressure data during the first compilation and uses it during the second compilation to make informed inlining decisions. The compiler saves two kinds of data during the first compilation: (1) the maximum register-pressure occurring in each procedure; and (2) within each procedure, the register pressure at each call site that is a potential inlining candidate. This data is then fed into the compiler during the second compilation. The compiler uses the data during the second compilation in two ways. First, when deciding whether to inline a child procedure into a parent procedure, the compiler determines whether the sum of the maximum register-pressure and the site register-pressure exceeds the number of available, physical registers.

Abstract: Debugger impact reduction through motion of an induction variable based breakpoint (“IV-breakpoint”) set within a program loop, where the IV-breakpoint and the loop are controlled by an induction variable having an induction rate, may include extracting, from program code within the program loop, the induction rate; extracting, from the IV-breakpoint, a final value of the induction variable for which the IV-breakpoint would be satisfied; and if the IV-breakpoint is satisfied and the induction variable has a present value that would be beyond the final value upon a next iteration of the loop based on the induction rate, removing the IV-breakpoint. Debugger impact reduction may further include setting, at one or more loop exit program positions, a reset breakpoint; and if one of the reset breakpoints is satisfied, removing the reset breakpoints and/or reestablishing the IV-breakpoint.

Abstract: A profile-based loop optimizer generates an execution frequency table for each loop that gives more detailed profile data that allows making a more intelligent decision regarding if and how to optimize each loop in the computer program. The execution frequency table contains entries that correlate a number of times a loop is executed each time the loop is entered with a count of the occurrences of each number during the execution of an instrumented instruction stream. The execution frequency table is used to determine whether there is one dominant mode that appears in the profile data, and if so, optimizes the loop according to the dominant mode. The optimizer may perform optimizations by peeling a loop, by unrolling a loop, and by performing both peeling and unrolling on a loop according to the profile data in the execution frequency table for the loop.

Abstract: Method and system for a software debugger tool. Breakpoints are submitted, as breakpoint data, by a user. A breakpoint manager stores the breakpoint data and inserts the breakpoints into the software program code. The breakpoint manager gains control of the program when a breakpoint is processed associated with a particular job. After the breakpoint manager completes an interrupt routine to process the breakpoint, using instructions stored in the breakpoint data, the method removes breakpoints associated with the particular job. When control is to be returned to the program, only those breakpoints that are found to be useful are set.

Abstract: A compiler and method of compiling provide enhanced performance by utilizing a skip list data structure to store various properties of a program at points of interest in the procedure, for example, the properties of the statements in each block in the control flow graph. A special procedure is used to initialize the skip list, prior to performing data flow analysis, to ensure that the skip list structure is not used in an inefficient manner as a result of initialization. Furthermore, special procedures are used to simultaneously scan and compare two skip lists as part of solving dataflow equations.

Abstract: A first type of debugger impact reduction includes removing, from within a loop, an initial conditional breakpoint (“ICB”); extracting a first Boolean expression (“BE_1”) therefrom; setting a special conditional breakpoint (“SCB”) including the BE_1; and reestablishing the ICB if the SCB is satisfied. Optionally, the first type may further include extracting, from code within the loop, a second Boolean expression (“BE_2”); disjunctively including its complement in the SCB; and setting a reset breakpoint at loop exit program positions to remove reset breakpoints and/or the ICB. A second type includes setting the SCB with the complement of BE_1; and removing the ICB when the SCB is satisfied. Optionally, the second type may further include conjunctively including the BE_2 in the SCB; and setting a reset breakpoint to remove reset breakpoints and/or reestablish the ICB. The above may be embodied in a method, a program debugger and an article of manufacture.

Abstract: An apparatus, program product, and method utilize routine cloning to optimize the performance of a compiled computer program. Within a compiled representation of a computer program, an implementation of a called routine is generated that has the same external response as the original routine, but is modified from the original routine to calculate the result of an expression, which was originally provided as an input parameter to the routine, within the body of the routine. In addition, the signature of the new implementation of the routine is modified to accept, in lieu of the input parameter that originally received the result of the expression, one or more input parameters representative of the argument(s) to be operated upon by the expression.

Abstract: A debugger capable of providing warnings for unreachable breakpoints is disclosed. After a breakpoint has been set by a user, within an application program source code that is monitored by a debugger, a debugger determines whether or not the breakpoint is set on a statement listed in an unreachable statement list. If the breakpoint is set on a statement listed in an unreachable statement list, the debugger displays an unreachable breakpoint warning to the user.

Abstract: A compiler for object-oriented programming code in a language which employs run-time static initialization semantics analyzes the static initialization code to find a subset of initialization statements which must execute under all conditions, creates an pre-initialized image of the static storage using the subset, and removes statements which were pre-initialized from the final compiled code. Preferably, the compiler is a back-end compiler for the Java language, which converts Java bytecode into machine executable instructions. A static initializer method for each class is decomposed to construct a control flow graph for the method, which is then analyzed to identify statements in the source which must necessarily execute whenever the initialization method is called. The compile-time static storage image is pre-initialized to zero, except where affected by these identified statements, which are set at compile time as if the identified statements had executed.

Abstract: Program execution profile data is collected by direct measurement of some code paths, and by inferring data for unmeasured paths. The data collection process may cause errors, which are propagated by the inferencing process. The profile data thus constructed is further enhanced by detecting certain data mismatches, and adjusting inferred data to reduce the scope of errors propagated during the inferencing process. Preferably, a control flow graph of the program being measured is constructed. Mismatches in the total weights of input arcs versus output arcs are detected. For certain specific types of mismatches, it can be known or guessed which count is incorrect, and this count is accordingly corrected. Correction of arc counts proceeds recursively until it is no longer possible to correct mismatches. Additionally, certain other conditions are adjusted as presumed inaccuracies.

Abstract: A mechanism and method for hoisting invariant computations from loops analyzes the lifetimes of fixed processor resources defined by an instruction, and determines whether a group of computations present in multiple instructions within the lifetime are, taken together, loop-invariant and legal to hoist from the loop. If the group of computations within the lifetime of the fixed processor resource are loop-invariant and hoistable, all of the computations are hoisted out of the loop as a group. By determining the lifetimes of fixed processor resources defined in an instruction, the hoisting mechanism succeeds in hoisting out groups of computations that cannot be individually hoisted out of a loop, thereby achieving better performance when the computer program executes.

Abstract: A superblock unroller creates a superblock in a first instruction stream, and unrolls the superblock using different methods depending on the suitability of the superblock to different types of unrolling. The superblock unroller uses complete unrolling if a number of iterations of the superblock is sufficiently small and if the number of iterations is known at compile-time. The superblock unroller uses static unrolling if the number of iterations of the superblock is too large for complete unrolling and if the number of iterations is known at compile-time. The superblock unroller uses dynamic unrolling if the number of iterations of the superblock is unknown at compile-time. Each of these unrolling methods may include the insertion of count rectification code into the first instruction stream to account for execution that exits the superblock. Code performance may be improved by providing the sophisticated unrolling of superblocks disclosed herein.

Abstract: An object oriented mechanism and method allow allocating Java objects on a method's invocation stack in a dynamic compilation environment under certain conditions. When a class is dynamically compiled by a just-in-time (JIT) compiler (as the program runs), one or more of its methods may create objects that may be placed on the method's invocation stack. During the compilation of the class, only the information relating to the previously-loaded classes is taken into account. After compilation, as each new class is loaded, the class is analyzed to see if loading the class might change the analysis used to allocate objects on the invocation stacks of previously-compiled methods. If so, the previous object allocations are analyzed in light of the object reference(s) in the newly loaded class, and the previous object allocations are changed from the invocation stack to the heap, if required.

Abstract: An object oriented mechanism and method allow allocating Java array objects of unknown size at compile time to a method's invocation stack if the array's size is less than a predetermined threshold value. If the array object could typically be allocated to the invocation stack if it were of a known size at compile time, run-time code is generated that examines the actual size of the array object at run-time and that allocates the array object to the invocation stack if the size is less than a predetermined threshold value. In this manner Java array objects that have an unknown size at compile time may still be allocated to an invocation stack at run-time if the size of the object is sufficiently small.

Abstract: Disclosed is a system and method for a profiling system wherein profile data is stored in a separable hierarchical fashion such that profile data for each compiled procedure in a computer program can be readily identified and utilized. In particular, each source module has a corresponding profile data file and each procedure has a corresponding procedure profile area. The system and method also includes a mechanism for verifying the existence and validity of profile information, and a mechanism for handling invalid profile information.

Abstract: A profile-based loop optimizer generates an execution frequency table for each loop that gives more detailed profile data that allows making a more intelligent decision regarding if and how to optimize each loop in the computer program. The execution frequency table contains entries that correlate a number of times a loop is executed each time the loop is entered with a count of the occurrences of each number during the execution of an instrumented instruction stream. The execution frequency table is used to determine whether there is one dominant mode that appears in the profile data, and if so, optimizes the loop according to the dominant mode. The optimizer may perform optimizations by peeling a loop, by unrolling a loop, and by performing both peeling and unrolling on a loop according to the profile data in the execution frequency table for the loop.

Abstract: A debugger capable of providing warnings for unreachable breakpoints is disclosed. After a breakpoint has been set by a user, within an application program source code that is monitored by a debugger, a debugger determines whether or not the breakpoint is set on a statement listed in an unreachable statement list. If the breakpoint is set on a statement listed in an unreachable statement list, the debugger displays an unreachable breakpoint warning to the user.

Abstract: In an exemplary aspect of the invention, a method for displaying a computer program organization on a screen monitor provides a graphical representation of a source code structure during a debugging session. The graphical representation may include a program call graph (PCG) or portion thereof for a procedure within the source code. The PCG may comprise a P_node to symbolize a procedure and an association reference to identify the relationship between two such procedures. Alternatively, the graphical representation may include a control flow graph (CFG) or portion thereof associated with a procedure within the source code. The procedure may comprise of one or more basic blocks, each basic block associated with a potentially executable source code statement. The CFG may comprise a B_node symbolizing a first basic block and an association reference to identify the relationship between two such basic blocks.

Abstract: An apparatus, program product, and method utilize routine cloning to optimize the performance of a compiled computer program. Within a compiled representation of a computer program, an implementation of a called routine is generated that has the same external response as the original routine (i.e., has the same output or result in response to the same input), but is modified from the original routine to calculate the result of an expression, which was originally provided as an input parameter to the routine, within the body of the routine. In addition, the signature of the new implementation of the routine is modified to accept, in lieu of the input parameter that originally received the result of the expression, one or more input parameters representative of the argument(s) to be operated upon by the expression.

Abstract: A front-end compiler generates unique instructions for virtual method calls in intermediate representation code that may be passed to a back-end compiler. A back-end compiler in accordance with the preferred embodiments receives the intermediate representation code, and processes the unique instructions to generate therefrom equivalent code with explicit method calls, where possible. The machine code from the back-end compiler is then executed using sample inputs to generate profile data. The profile data and intermediate representation code are fed into the back-end compiler, which then generates code that may devirtualize virtual method calls according to the profile data by providing one or more explicit method calls for target methods that have an execution frequency (as indicated by the profile data) that exceeds a predetermined threshold.