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.

Abstract: A method and apparatus for debugging computer programs that provides means for inserting breakpoints at program logic decision points that may have caused an event to occur. Such an event may be an unexpected halt, the execution of unexpected program statements, or the assignment to a variable of an unexpected value. A Control Flow Graph (CFG) is provided that represents the possible flows through the computer program as a sequence of basic blocks. A Control Dependence Graph (CDG) is provided that maps each basic block in the computer program to those other blocks that may determine whether the first block will be executed. The information in the CFG and CDG is used to determine where the breakpoints should be set.

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: Method, system and article of manufacture for monitoring variables. In one embodiment, information generated by a compiler is used to determine which variables need to be updated when performing a step, a “run to cursor” operation, and when a breakpoint is hit. This may be accomplished by providing as debugger data which variables may be affected at each statement of a program and a control flow graph for the program or procedure. The information about which variables may be affected can be stored as individual variables or sets of variables. When execution of the program being debugged is halted, only those variables whose values may have changed are refreshed in a variables window of a user interface.

Abstract: A method, apparatus and article of manufacture for displaying computer program variables on a display device when debugging the computer program. In general, the executable status of variables is determined. The variables are then displayed on a display device in manner to differentiate the different executable statuses of the variables. In one embodiment, a first executable status indicates that a variable can change value when the computer program is executing. In another embodiment, a second executable status indicates that a current value of a variable may have a use.

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 object oriented mechanism and method allow allocating a greater number of objects on a method's invocation stack. Each instruction that creates an object (i.e., allocation instruction) is first analyzed to determine whether it is one of the following three types: no escape, global escape, and arg escape. If an allocation instruction is global escape, the object must be allocated from the heap. If an allocation instruction is no escape, it can be allocated on the method's invocation stack frame. If an allocation instruction is arg escape, further analysis is required to determine whether the object can be allocated on an invoking method's stack or must be allocated from the heap. If the method that contains an arg escape allocation instruction can be inlined into a method from which the lifetime of the object does not escape, the object can be allocated on the invoking method's stack. This inlining can be done for several layers up, if needed and possible.

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: An object oriented mechanism and method allow allocating Java objects on a method's invocation stack in a partial compilation environment under certain conditions. Only the classes that are visible are taken into account when performing escape analysis in accordance with the preferred embodiments. In a first aspect of the invention, conservative assumptions are made to assure that objects are only allocated on an invocation stack when this can be proven safe by examining only those classes in the compilation unit. In a second aspect of the invention, the concept of visible classes is extended to include other classes that may be found from a user-defined classpath that matches the anticipated run-time classpath used to find classes during program execution. When stack allocation decisions for a method depends on such classes that are outside the compilation unit, two versions of run time code for that method are created.