CA2306519A1 - Method and apparatus for handling exceptions as normal control flow - Google Patents
Method and apparatus for handling exceptions as normal control flow Download PDFInfo
- Publication number
- CA2306519A1 CA2306519A1 CA002306519A CA2306519A CA2306519A1 CA 2306519 A1 CA2306519 A1 CA 2306519A1 CA 002306519 A CA002306519 A CA 002306519A CA 2306519 A CA2306519 A CA 2306519A CA 2306519 A1 CA2306519 A1 CA 2306519A1
- Authority
- CA
- Canada
- Prior art keywords
- code
- computer
- exception
- source code
- internal representation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
- G06F8/4434—Reducing the memory space required by the program code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/48—Indexing scheme relating to G06F9/48
- G06F2209/481—Exception handling
Abstract
Methods and apparatus for handling exceptions as a part of normal program control flow are disclosed. According to one aspect of the present invention, a method for processing an exception in an object-based system includes obtaining source code that includes a code segment which is arranged to explicitly specify instructions pertaining to an exception check. The method also includes creating a final internal representation of the source code at least in part by removing a call associated with the exception check, and generating machine code associated with the final internal representation. In one embodiment, the method further includes executing the machine code.
Description
Method and Apparatus for Handlin,~ Exceptions as Normal Control Flow Invented By:
Clifford N. Click, Jr., Christopher A. Vick, and Michael H. Paleczny s BACKGROUND OF THE INVENTION
1. Field of Invention The present invention relates generally to methods and apparatus for improving the performance of software applications. More particularly, the present invention relates to methods and apparatus for processing exceptions as a part of the 1 o normal control flow of a computer program.
Clifford N. Click, Jr., Christopher A. Vick, and Michael H. Paleczny s BACKGROUND OF THE INVENTION
1. Field of Invention The present invention relates generally to methods and apparatus for improving the performance of software applications. More particularly, the present invention relates to methods and apparatus for processing exceptions as a part of the 1 o normal control flow of a computer program.
2. Description of the Related Art In an effort to increase the efficiency associated with the execution of computer programs, many computer programs are "optimized." Optimizing a ~ 5 computer program generally serves to eliminate portions of computer code which are essentially unused. In addition, optimizing a computer program may restructure computational operations to allow overall computations to be performed more efficiently, thereby consuming fewer computer resources.
2o An optimizer is arranged to effectively transform a computer program, e.g., a computer program written in a programming language such as C++, FORTRAN or Java bytecodes into a faster program. The faster, or optimized, program generally includes substantially all the same, observable behaviors as the original, or pre-converted, computer program. Specifically, the optimized program includes the same 2s mathematical behavior has its associated original program. However, the optimized program generally recreates the same mathematical behavior with fewer computations.
Optimizers are generally arranged to handle exceptions associated with a 3o computer program. As will be appreciated by those skilled in the art, an exception is typically an event or a condition that requires processing outside of the normal control flow. As the name "exception" implies, it is intended to signal rare, or exceptional, events. While it is possible for programs to use exceptions in their normal handling, the handling of exceptions is usually associated with rare error conditions.
Exceptions associated with computer programs typically either involve array range checks or invalid pointer accesses.
A range check is implemented in a computer program to ascertain whether a reference to an array stays within the bounds of the array. Specialized code may be included in a computer program to handle a range check. When a reference to an array does not stay within the bounds of the array, an exception may be raised to indicate that the reference is out of the bounds of the array.
to An invalid pointer reference generally involves using a pointer that does not point to any valid memory location. In some programming languages, e.g., the JavaTM programming language developed by Sun Microsystems, Inc. of Palo Alto, California, a pointer either points to a valid memory location or is the null value.
~ 5 When a null pointer is referenced, an exception is thrown. In some cases, redundant tests for null pointers, i.e., "null checks," may occur. When a first test indicates that a pointer is not the null value, a second test that is arranged to test whether a pointer is the null value is a redundant test. As will be appreciated by those skilled in the art, a test for a null pointer is implicitly performed when an attempt is made to load the 20 contents associated with a pointer.
Figure 1 a is a diagrammatic representation of a source code which includes commands to load pointers and, hence, implicitly includes null checks. Source code 102 includes commands, or instructions, to load contents associated with pointers into 25 registers. By way of example, a command 103 is a command to load the contents of a field "A" through pointer "ptrl." When such a command occurs, the central processing unit [CPU] hardware makes a check to determine if the pointer is a valid pointer. For the JavaTM programming language, the only invalid pointer is the null pointer. Hence, the check by the CPU hardware check is essentially a check for the 30 null pointer. A command 104 is also a command to load through pointer "ptrl."
Although a determination has generally already made regarding whether pointer "ptrl" is null with respect to command 103, an essentially redundant check regarding whether pointer "ptrl" is generally made with respect to command 104. Source code 102 is provided to an optimizer 106 which is arranged to optimize source code 102.
Once an optimization process is completed, then machine code 110 associated with source code 102 is created.
When an exception is thrown in response to the identification of a null pointer, a table is typically accessed to process the exception. Such a table is often a look-up table that maps a type of exception to a suitable code segment for handling the exception. Figure lb is a diagrammatic representation of code which handles exceptions and accesses a look-up table to process the exceptions. A code representation 152 includes calls arranged to throw different types of exceptions. A
t o call 154 to a function that throws a "TrueException" results in a look-up table 160 being accessed. Specifically, the "TrueException" is used as an index into look-up table 160 such that an appropriate segment of code associated with the throwing of a "TrueException." As shown, a segment of code 157 is eventually accessed by call 154. Similarly, a call 156 to a function that throws a "FalseException" maps to a ~ 5 segment of code 158 through look-up table 160.
In general, each time an exception is thrown, e.g., each time a call is made to a function that throws a "TrueException," storage is allocated to an exception object.
That is, an exception object is created for each exception that is thrown.
Such 2o exception objects are often never used, as will be appreciated by those skilled in the art. However, exception objects are considered to be in use and, hence, are not eliminated by an optimizer during an optimization process. Therefore, the time to initialize exception objects and the memory space occupied by exception objects is effectively wasted as the memory space may not be reallocated for alternative uses.
In a programming language such as the JavaTM programming language, precise exception handling is typically required. Precise exception handling generally requires that exception checks be neither reordered nor removed. As such, redundant code is often associated with the handling of an exception such as a null pointer 3o exception, as previously mentioned.
Although specific exception handling code may be relatively effective in handling exceptions, since the code that handles exceptions is often redundant, the optimization of source code which includes exception handling code may not be complete. In other words, an optimization process may not produce a program that is optimized as much as possible. When a program is not completely optimized, the program may not execute efficiently. Further, as previously mentioned, each time an exception is thrown, storage is allocated to an exception object. Since exception objects are generally not used, redundant exception objects created from redundant exception code increase the amount of wasted.memory space associated with a computer system.
In order to further optimize programs with precise exceptions, optimizers typically include special optimization techniques to handle the exceptions.
The presence of these special techniques requires custom code to be added to the optimizer. This custom code is a often a source of subtle bugs. Further, such custom code is often not well integrated into the rest of the optimizer, and will not be able to remove some exception checks that could be removed if the full power of the 15 optimizer could be brought to bear.
Therefore, what is desired is an efficient method for handling exceptions.
Specifically, what is needed is a method and an apparatus for substantially eliminating redundant exception checks by enabling an optimizer to handle exceptions as part of 2o normal program control flow.
SUMMARY OF THE INVENTION
The present invention relates to handling exceptions as a part of normal 25 program control flow. According to one aspect of the present invention, a method for processing an exception in an object-based system includes obtaining source code that includes a code segment which is arranged to explicitly specify instructions pertaining to an exception check. The method also includes creating a final internal representation of the source code at least in part by removing a call associated with 30 .the exception check, and generating machine code associated with the final internal representation. In one embodiment, the method further includes executing the machine code.
By integrating the handling of exceptions into normal program control flow, the efficiency of handling exceptions may be increased. For instance, exceptions which are handled as part of normal program control flow may have redundant checks eliminated by the mechanism which removes redundant checks in normal control flow. Additionally, exception objects which are never used may be eliminated when exceptions are handled as part of normal program control flow, i.e., the optimizer already removes unused code and with this invention may also remove code associated with exceptions, thereby freeing resources associated with the exception objects.
According to another aspect of the present invention, a method for creating a representation of source code with code portions associated with exceptions includes first obtaining the source code. The source code includes a first code portion that is nested within a second code portion. A determination is made as to whether the first 1 s code portion is redundant with respect to the second code portion, and a transformation is performed to change the source code into an internal representation.
Such a transformation of the source code into an internal representation includes eliminating the first code portion from the source code when it is determined that the first code portion is redundant with respect to the second code portion. In one 2o embodiment, the internal representation is further transformed into machine code.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.
2s BRIEF DESCRIPTION OF THE DRAWINGS
The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:
3o Figure la is a diagrammatic representation of a source code which implicitly includes null checks and machine code, which is generated by an optimizer, that is associated with the source code.
Figure lb is a diagrammatic representation of machine code that handles exceptions as part of its normal execution.
Figure 2 is a diagrammatic representation of the action of an optimizer that integrates exception handling into normal program control flow in accordance with an embodiment of the present invention, as the optimizer operates on a program which uses exceptions.
Figure 3 is a process flow diagram which illustrates the steps associated with optimizing source code with explicit exception flow in accordance with an embodiment of the present invention.
Figure 4 is a diagrammatic representation of a computer program with explicit exception flow that has been processed by an optimizer in accordance with an 1 o embodiment of the present invention.
Figure 5 is a diagrammatic representation of a general purpose computer system suitable for implementing the present invention.
Figure 6 is a diagrammatic representation of a virtual machine which is supported by the computer system of Figure S, and is suitable for implementing the ~ 5 present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
2o Precise exception handling is often required in a programming language such as the JavaTM programming language developed by Sun Microsystems, Inc. of Palo Alto, California. Precise exception handling generally requires that exception checks not be reordered or removed, unless it may be proven that no exception may occur in a particular area, and may require specific exception handling code to be 25 implemented. For each exception, code that is arranged to handle the exception may be required. As such, redundant code is often associated with the handling of an exception such as a null pointer exception. For example, redundant code is present in a test of whether a particular pointer is null if that test occurs after it has already been determined that the particular pointer is not null. As will be understood by those 3o skilled in the art, a null pointer is generally a pointer that does not reference memory but, instead, contains a null value. When a null pointer is referenced, an exception is thrown.
SUN t P226 6 Processing redundant exception handling code to determine whether a pointer is null is both unnecessary and inefficient when it has already been determined that a particular pointer is not a null pointer. While specific exception handling code is relatively effective in handling exceptions, the optimization of source code which includes redundant exception handling code is generally not considered to be complete. That is, such source code may be further optimized. When a program is not completely optimized, the program may execute somewhat inefficiently.
By including exception processing instructions explicitly within the normal control flow of a computer program, the computer program may be transformed by an optimizer to remove instructions associated with the processing of redundant exceptions. In other words, explicitly coding exception processing instructions into a computer program enables that computer program to be optimized to remove redundant exception handling code. Further, integrating exception handling into the 15 normal flow of a computer program serves to enable objects created when exceptions are thrown to be removed during an optimization process. Hence, machine code generated from a program with integrated exception handling typically execute more efficiently than machine code generated from a program with specific exception handling code.
Figure 2 is a diagrammatic representation of an optimizer which integrates exception handling into normal program control flow in accordance with an embodiment of the present invention. Source code 202 which explicitly specifies exception flow, e.g., program flow associated with processing an exception, is provided as an input to an optimizer 222. Optimizer 222 is generally arranged to transform source code 202 into machine code 242 that is the mathematical computational equivalent of source code 202.
In the described embodiment, optimizer 222 creates an intermediate internal 3o representation 226 of source code 202 based upon a language such as the JavaTM
programming language. Intermediate internal representation 226 may be considered to be a "literal" representation of source code 202 in that the program flow associated with intermediate internal representation 226 is substantially unoptimized.
Intermediate internal representation 226 includes calls 228 to functions which are arranged to throw exceptions. Such functions may access a look-up table that maps a particular exception to a segment of code that is associated with the particular exception. Such look-up table mappings may be converted into traditional "goto"
commands, in one embodiment.
The optimizer is arranged such that it may remove extra "goto" commands as part of its normal processing. In addition, optimizer 222 optimizes intermediate internal representation 226 such that unused, e.g., dead, code may be excluded from final internal representation 230. Final internal representation 230 is used by optimizer 222 to create machine code 242. As shown, calls 228 which are present in intermediate internal representation 226 may be eliminated from final internal representation 230, while still enabling final internal representation 230 to be the computational equivalent of intermediate internal representation 226. In other words, final internal representation 230 is effectively a simplification of intermediate internal 1 s representation 226. By eliminating calls 228 to functions which throw exceptions, unused exception objects that are created in response to thrown exceptions may be substantially eliminated.
With reference to Figure 3, the steps associated with a process of creating 2o machine code in which exception handling is integrated into normal control flow will be described in accordance with an embodiment of the present invention. A
process 300 of creating machine code begins at step 302 in which a program with implicit exception flow is obtained by an optimizer. An example of a program with implicit exception flow will be described below with respect to Figure 4.
After an optimizer obtains the program, then an intermediate internal representation of the program is created in step 304. In general, the intermediate internal representation of the program has all implicit exception flow made explicit and includes explicit exception checks. Additionally, the intermediate internal 3o representation includes calls to exception handlers. In step 306, the intermediate internal representation is optimized. During the optimization process, the optimizer removes substantially all redundant exceptions checks and dead code associated with calls to exceptions, in addition to other optimizations. That is, the optimizer optimizes the intermediate internal representation by removing unused code.
Other optimizations include, but are not limited to, performing table lookups associated with exception throws, and converting throw instructions into "goto" instructions.
From step 306, process flow moves to step 308 where a final internal representation of the program is created from the intermediate internal representation.
As will be appreciated by those skilled in the art, the final internal representation is generated when unused code, or dead code, is removed from the corresponding intermediate internal representation. The final internal representation integrates exception handling into normal control flow, as previously discussed with reference to t o Figure 2. After the final internal representation of the program is created in step 308, then the optimizer creates machine code from the final internal representation. Once the machine code is produced, the process of creating machine code that integrates exception handling into normal control flow is created.
i 5 As mentioned above, an optimizer that is arranged to optimize a computer program with implicit exception flow allows redundant exception checks to be eliminated. Figure 4 is a diagrammatic representation of a computer program with explicit exception flow that is processed by an optimizer to remove redundant exceptions in accordance with an embodiment of the present invention. An optimizer 2o 410 is generally arranged to eliminate sections of unused code from source code 402 in order to optimize the performance associated with machine code 420, i.e., machine code generated by optimizer 410. In addition, optimizer 410 typically checks computations performed within source code 402, and removes computations which it proves as being unnecessary, e.g., redundant.
Source code 402, which explicitly specifies exception flow, includes an instruction 404 to throw an exception when a pointer "ptrl" is found to be a null pointer. When pointer "ptrl" is determined not to be a null pointer, then additional instructions 406, 408 are processed as a part of the normal control flow associated 3o with source code 402. Instruction 408 is a redundant test of whether pointer "ptrl" is a null pointer, as instruction 408 may only be reached in normal control flow when instruction 404 results in a determination that pointer "ptrl" is not a null pointer.
Optimizer 410 is arranged to determine that instruction 408 is unnecessary in light of instruction 404. Once optimizer 410 determines that instruction 408 is a redundant StJN 1 P226 9 instruction, optimizer 410 may eliminate instruction 408 and create machine code 420. In machine code 420, the loading of register RZ is hoisted above the loading of register RY, thereby allowing the relatively slow divide (DIV) instruction to begin execution sooner. This allows the loading of RY and the divide instruction to overlap in time, creating a faster program. As discussed above with respect to Figure 3, in one embodiment, optimizer 410 also integrates the processing of exceptions into normal control flow of an internal representation (not shown) and, hence, machine code 420.
Figure 5 illustrates a typical, general purpose computer system suitable for implementing the present invention. The computer system 1030 includes any number of processors 1032 (also referred to as central processing units, or CPUs) that are coupled to memory devices including primary storage devices 1034 (typically a random access memory, or RAM) and primary storage devices 1036 (typically a read 15 only memory, or ROM).
Computer system 1030 or, more specifically, CPU 1032, may be arranged to support a virtual machine, as will be appreciated by those skilled in the art.
One example of a virtual machine that is supported on computer system 1030 will be 2o described below with reference to Figure 6. As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU 1032, while RAM is used typically to transfer data and instructions in a bi-directional manner. CPU
1032 may generally include any number of processors. Both primary storage devices 1034, 1036 may include any suitable computer-readable media. A secondary storage 25 medium 1038, which is typically a mass memory device, is also coupled bi-directionally to CPU 1032 and provides additional data storage capacity. The mass memory device 1038 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, mass memory device 1038 is a storage medium such as a hard disk or a tape which is generally 3o slower than primary storage devices 1034, 1036. Mass memory storage device may take the form of a magnetic or paper tape reader or some other well-known device. It will be appreciated that the information retained within the mass memory device 1038, may, in appropriate cases, be incorporated in standard fashion as part of RAM 1036 as virtual memory. A specific primary storage device 1034 such as a CD-ROM may also pass data uni-directionally to the CPU 1032.
CPU 1032 is also coupled to one or more input/output devices 1040 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU
optionally may be coupled to a computer or telecommunications network, e.g., a local 1 o area network, an Internet network or an intranet network, using a network connection as shown generally at 1012. With such a network connection, it is contemplated that the CPU 1032 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using CPU 1032, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.
As previously mentioned, a virtual machine may execute on computer system 1030. Figure 6 is a diagrammatic representation of a virtual machine which is supported by computer system 1030 of Figure 5, and is suitable for implementing the present invention. When a computer program, e.g., a computer program written in the JavaTM programming language developed by Sun Microsystems of Palo Alto, California, is executed, source code 1110 is provided to a compiler 1120 within a compile-time environment 1105. Compiler 1120 translates source code 1110 into byte codes 1130. In general, source code 1110 is translated into byte codes 1130 at the time source code 1110 is created by a software developer.
3o Byte codes 1130 may generally be reproduced, downloaded, or otherwise distributed through a network, e.g., network 1012 of Figure 5, or stored on a storage device such as primary storage 1034 of Figure 5. In the described embodiment, byte codes 1130 are platform independent. That is, byte codes 1130 may be executed on substantially any computer system that is running a suitable virtual machine 1140. By way of example, in a JavaTM environment, byte codes 1130 may be executed on a computer system that is running a JavaTM virtual machine.
Byte codes 1130 are provided to a runtime environment 1135 which includes virtual machine 1140. Runtime environment 1135 may generally be executed using a processor such as CPU 1032 of Figure 5. Virtual machine 1140 includes a compiler 1142, an interpreter 1144, and a runtime system 1146. Byte codes 1130 may generally be provided either to compiler 1142 or interpreter 1144.
1o When byte codes 1130 are provided to compiler 1142, methods contained in byte codes 1130 are compiled into machine instructions, as described above. On the other hand, when byte codes 1130 are provided to interpreter 1144, byte codes are read into interpreter 1144 one byte code at a time. Interpreter 1144 then performs the operation defined by each byte code as each byte code is read into interpreter i 5 1144. In general, interpreter 1144 processes byte codes 1130 and performs operations associated with byte codes 1130 substantially continuously.
When a method is called from an operating system 1160, if it is determined that the method is to be invoked as an interpreted method, runtime system 1146 may 20 obtain the method from interpreter 1144. If, on the other hand, it is determined that the method is to be invoked as a compiled method, runtime system 1146 activates compiler 1142. Compiler 1142 then generates machine instructions from byte codes 1130, and executes the machine-language instructions. In general, the machine-language instructions are discarded when virtual machine 1140 terminates.
Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the invention. By way of example, steps involved with creating machine code from 3o source code that specifies explicit exception flow may be reordered, removed or added. In general, steps involved with the methods of the present invention may be reordered, removed, or added without departing from the spirit or the scope of the presentinvention.
While exception handling as a part of the normal control flow of a computer program has generally been described as being associated with a JavaT"' environment, it should be appreciated' that such exception handling may be implemented in substantially any suitable environment. By way of example, in lieu of an environment associated with a JavaTM virtual machine, environments associated with other virtual machine may be implemented. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims.
2o An optimizer is arranged to effectively transform a computer program, e.g., a computer program written in a programming language such as C++, FORTRAN or Java bytecodes into a faster program. The faster, or optimized, program generally includes substantially all the same, observable behaviors as the original, or pre-converted, computer program. Specifically, the optimized program includes the same 2s mathematical behavior has its associated original program. However, the optimized program generally recreates the same mathematical behavior with fewer computations.
Optimizers are generally arranged to handle exceptions associated with a 3o computer program. As will be appreciated by those skilled in the art, an exception is typically an event or a condition that requires processing outside of the normal control flow. As the name "exception" implies, it is intended to signal rare, or exceptional, events. While it is possible for programs to use exceptions in their normal handling, the handling of exceptions is usually associated with rare error conditions.
Exceptions associated with computer programs typically either involve array range checks or invalid pointer accesses.
A range check is implemented in a computer program to ascertain whether a reference to an array stays within the bounds of the array. Specialized code may be included in a computer program to handle a range check. When a reference to an array does not stay within the bounds of the array, an exception may be raised to indicate that the reference is out of the bounds of the array.
to An invalid pointer reference generally involves using a pointer that does not point to any valid memory location. In some programming languages, e.g., the JavaTM programming language developed by Sun Microsystems, Inc. of Palo Alto, California, a pointer either points to a valid memory location or is the null value.
~ 5 When a null pointer is referenced, an exception is thrown. In some cases, redundant tests for null pointers, i.e., "null checks," may occur. When a first test indicates that a pointer is not the null value, a second test that is arranged to test whether a pointer is the null value is a redundant test. As will be appreciated by those skilled in the art, a test for a null pointer is implicitly performed when an attempt is made to load the 20 contents associated with a pointer.
Figure 1 a is a diagrammatic representation of a source code which includes commands to load pointers and, hence, implicitly includes null checks. Source code 102 includes commands, or instructions, to load contents associated with pointers into 25 registers. By way of example, a command 103 is a command to load the contents of a field "A" through pointer "ptrl." When such a command occurs, the central processing unit [CPU] hardware makes a check to determine if the pointer is a valid pointer. For the JavaTM programming language, the only invalid pointer is the null pointer. Hence, the check by the CPU hardware check is essentially a check for the 30 null pointer. A command 104 is also a command to load through pointer "ptrl."
Although a determination has generally already made regarding whether pointer "ptrl" is null with respect to command 103, an essentially redundant check regarding whether pointer "ptrl" is generally made with respect to command 104. Source code 102 is provided to an optimizer 106 which is arranged to optimize source code 102.
Once an optimization process is completed, then machine code 110 associated with source code 102 is created.
When an exception is thrown in response to the identification of a null pointer, a table is typically accessed to process the exception. Such a table is often a look-up table that maps a type of exception to a suitable code segment for handling the exception. Figure lb is a diagrammatic representation of code which handles exceptions and accesses a look-up table to process the exceptions. A code representation 152 includes calls arranged to throw different types of exceptions. A
t o call 154 to a function that throws a "TrueException" results in a look-up table 160 being accessed. Specifically, the "TrueException" is used as an index into look-up table 160 such that an appropriate segment of code associated with the throwing of a "TrueException." As shown, a segment of code 157 is eventually accessed by call 154. Similarly, a call 156 to a function that throws a "FalseException" maps to a ~ 5 segment of code 158 through look-up table 160.
In general, each time an exception is thrown, e.g., each time a call is made to a function that throws a "TrueException," storage is allocated to an exception object.
That is, an exception object is created for each exception that is thrown.
Such 2o exception objects are often never used, as will be appreciated by those skilled in the art. However, exception objects are considered to be in use and, hence, are not eliminated by an optimizer during an optimization process. Therefore, the time to initialize exception objects and the memory space occupied by exception objects is effectively wasted as the memory space may not be reallocated for alternative uses.
In a programming language such as the JavaTM programming language, precise exception handling is typically required. Precise exception handling generally requires that exception checks be neither reordered nor removed. As such, redundant code is often associated with the handling of an exception such as a null pointer 3o exception, as previously mentioned.
Although specific exception handling code may be relatively effective in handling exceptions, since the code that handles exceptions is often redundant, the optimization of source code which includes exception handling code may not be complete. In other words, an optimization process may not produce a program that is optimized as much as possible. When a program is not completely optimized, the program may not execute efficiently. Further, as previously mentioned, each time an exception is thrown, storage is allocated to an exception object. Since exception objects are generally not used, redundant exception objects created from redundant exception code increase the amount of wasted.memory space associated with a computer system.
In order to further optimize programs with precise exceptions, optimizers typically include special optimization techniques to handle the exceptions.
The presence of these special techniques requires custom code to be added to the optimizer. This custom code is a often a source of subtle bugs. Further, such custom code is often not well integrated into the rest of the optimizer, and will not be able to remove some exception checks that could be removed if the full power of the 15 optimizer could be brought to bear.
Therefore, what is desired is an efficient method for handling exceptions.
Specifically, what is needed is a method and an apparatus for substantially eliminating redundant exception checks by enabling an optimizer to handle exceptions as part of 2o normal program control flow.
SUMMARY OF THE INVENTION
The present invention relates to handling exceptions as a part of normal 25 program control flow. According to one aspect of the present invention, a method for processing an exception in an object-based system includes obtaining source code that includes a code segment which is arranged to explicitly specify instructions pertaining to an exception check. The method also includes creating a final internal representation of the source code at least in part by removing a call associated with 30 .the exception check, and generating machine code associated with the final internal representation. In one embodiment, the method further includes executing the machine code.
By integrating the handling of exceptions into normal program control flow, the efficiency of handling exceptions may be increased. For instance, exceptions which are handled as part of normal program control flow may have redundant checks eliminated by the mechanism which removes redundant checks in normal control flow. Additionally, exception objects which are never used may be eliminated when exceptions are handled as part of normal program control flow, i.e., the optimizer already removes unused code and with this invention may also remove code associated with exceptions, thereby freeing resources associated with the exception objects.
According to another aspect of the present invention, a method for creating a representation of source code with code portions associated with exceptions includes first obtaining the source code. The source code includes a first code portion that is nested within a second code portion. A determination is made as to whether the first 1 s code portion is redundant with respect to the second code portion, and a transformation is performed to change the source code into an internal representation.
Such a transformation of the source code into an internal representation includes eliminating the first code portion from the source code when it is determined that the first code portion is redundant with respect to the second code portion. In one 2o embodiment, the internal representation is further transformed into machine code.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.
2s BRIEF DESCRIPTION OF THE DRAWINGS
The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:
3o Figure la is a diagrammatic representation of a source code which implicitly includes null checks and machine code, which is generated by an optimizer, that is associated with the source code.
Figure lb is a diagrammatic representation of machine code that handles exceptions as part of its normal execution.
Figure 2 is a diagrammatic representation of the action of an optimizer that integrates exception handling into normal program control flow in accordance with an embodiment of the present invention, as the optimizer operates on a program which uses exceptions.
Figure 3 is a process flow diagram which illustrates the steps associated with optimizing source code with explicit exception flow in accordance with an embodiment of the present invention.
Figure 4 is a diagrammatic representation of a computer program with explicit exception flow that has been processed by an optimizer in accordance with an 1 o embodiment of the present invention.
Figure 5 is a diagrammatic representation of a general purpose computer system suitable for implementing the present invention.
Figure 6 is a diagrammatic representation of a virtual machine which is supported by the computer system of Figure S, and is suitable for implementing the ~ 5 present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
2o Precise exception handling is often required in a programming language such as the JavaTM programming language developed by Sun Microsystems, Inc. of Palo Alto, California. Precise exception handling generally requires that exception checks not be reordered or removed, unless it may be proven that no exception may occur in a particular area, and may require specific exception handling code to be 25 implemented. For each exception, code that is arranged to handle the exception may be required. As such, redundant code is often associated with the handling of an exception such as a null pointer exception. For example, redundant code is present in a test of whether a particular pointer is null if that test occurs after it has already been determined that the particular pointer is not null. As will be understood by those 3o skilled in the art, a null pointer is generally a pointer that does not reference memory but, instead, contains a null value. When a null pointer is referenced, an exception is thrown.
SUN t P226 6 Processing redundant exception handling code to determine whether a pointer is null is both unnecessary and inefficient when it has already been determined that a particular pointer is not a null pointer. While specific exception handling code is relatively effective in handling exceptions, the optimization of source code which includes redundant exception handling code is generally not considered to be complete. That is, such source code may be further optimized. When a program is not completely optimized, the program may execute somewhat inefficiently.
By including exception processing instructions explicitly within the normal control flow of a computer program, the computer program may be transformed by an optimizer to remove instructions associated with the processing of redundant exceptions. In other words, explicitly coding exception processing instructions into a computer program enables that computer program to be optimized to remove redundant exception handling code. Further, integrating exception handling into the 15 normal flow of a computer program serves to enable objects created when exceptions are thrown to be removed during an optimization process. Hence, machine code generated from a program with integrated exception handling typically execute more efficiently than machine code generated from a program with specific exception handling code.
Figure 2 is a diagrammatic representation of an optimizer which integrates exception handling into normal program control flow in accordance with an embodiment of the present invention. Source code 202 which explicitly specifies exception flow, e.g., program flow associated with processing an exception, is provided as an input to an optimizer 222. Optimizer 222 is generally arranged to transform source code 202 into machine code 242 that is the mathematical computational equivalent of source code 202.
In the described embodiment, optimizer 222 creates an intermediate internal 3o representation 226 of source code 202 based upon a language such as the JavaTM
programming language. Intermediate internal representation 226 may be considered to be a "literal" representation of source code 202 in that the program flow associated with intermediate internal representation 226 is substantially unoptimized.
Intermediate internal representation 226 includes calls 228 to functions which are arranged to throw exceptions. Such functions may access a look-up table that maps a particular exception to a segment of code that is associated with the particular exception. Such look-up table mappings may be converted into traditional "goto"
commands, in one embodiment.
The optimizer is arranged such that it may remove extra "goto" commands as part of its normal processing. In addition, optimizer 222 optimizes intermediate internal representation 226 such that unused, e.g., dead, code may be excluded from final internal representation 230. Final internal representation 230 is used by optimizer 222 to create machine code 242. As shown, calls 228 which are present in intermediate internal representation 226 may be eliminated from final internal representation 230, while still enabling final internal representation 230 to be the computational equivalent of intermediate internal representation 226. In other words, final internal representation 230 is effectively a simplification of intermediate internal 1 s representation 226. By eliminating calls 228 to functions which throw exceptions, unused exception objects that are created in response to thrown exceptions may be substantially eliminated.
With reference to Figure 3, the steps associated with a process of creating 2o machine code in which exception handling is integrated into normal control flow will be described in accordance with an embodiment of the present invention. A
process 300 of creating machine code begins at step 302 in which a program with implicit exception flow is obtained by an optimizer. An example of a program with implicit exception flow will be described below with respect to Figure 4.
After an optimizer obtains the program, then an intermediate internal representation of the program is created in step 304. In general, the intermediate internal representation of the program has all implicit exception flow made explicit and includes explicit exception checks. Additionally, the intermediate internal 3o representation includes calls to exception handlers. In step 306, the intermediate internal representation is optimized. During the optimization process, the optimizer removes substantially all redundant exceptions checks and dead code associated with calls to exceptions, in addition to other optimizations. That is, the optimizer optimizes the intermediate internal representation by removing unused code.
Other optimizations include, but are not limited to, performing table lookups associated with exception throws, and converting throw instructions into "goto" instructions.
From step 306, process flow moves to step 308 where a final internal representation of the program is created from the intermediate internal representation.
As will be appreciated by those skilled in the art, the final internal representation is generated when unused code, or dead code, is removed from the corresponding intermediate internal representation. The final internal representation integrates exception handling into normal control flow, as previously discussed with reference to t o Figure 2. After the final internal representation of the program is created in step 308, then the optimizer creates machine code from the final internal representation. Once the machine code is produced, the process of creating machine code that integrates exception handling into normal control flow is created.
i 5 As mentioned above, an optimizer that is arranged to optimize a computer program with implicit exception flow allows redundant exception checks to be eliminated. Figure 4 is a diagrammatic representation of a computer program with explicit exception flow that is processed by an optimizer to remove redundant exceptions in accordance with an embodiment of the present invention. An optimizer 2o 410 is generally arranged to eliminate sections of unused code from source code 402 in order to optimize the performance associated with machine code 420, i.e., machine code generated by optimizer 410. In addition, optimizer 410 typically checks computations performed within source code 402, and removes computations which it proves as being unnecessary, e.g., redundant.
Source code 402, which explicitly specifies exception flow, includes an instruction 404 to throw an exception when a pointer "ptrl" is found to be a null pointer. When pointer "ptrl" is determined not to be a null pointer, then additional instructions 406, 408 are processed as a part of the normal control flow associated 3o with source code 402. Instruction 408 is a redundant test of whether pointer "ptrl" is a null pointer, as instruction 408 may only be reached in normal control flow when instruction 404 results in a determination that pointer "ptrl" is not a null pointer.
Optimizer 410 is arranged to determine that instruction 408 is unnecessary in light of instruction 404. Once optimizer 410 determines that instruction 408 is a redundant StJN 1 P226 9 instruction, optimizer 410 may eliminate instruction 408 and create machine code 420. In machine code 420, the loading of register RZ is hoisted above the loading of register RY, thereby allowing the relatively slow divide (DIV) instruction to begin execution sooner. This allows the loading of RY and the divide instruction to overlap in time, creating a faster program. As discussed above with respect to Figure 3, in one embodiment, optimizer 410 also integrates the processing of exceptions into normal control flow of an internal representation (not shown) and, hence, machine code 420.
Figure 5 illustrates a typical, general purpose computer system suitable for implementing the present invention. The computer system 1030 includes any number of processors 1032 (also referred to as central processing units, or CPUs) that are coupled to memory devices including primary storage devices 1034 (typically a random access memory, or RAM) and primary storage devices 1036 (typically a read 15 only memory, or ROM).
Computer system 1030 or, more specifically, CPU 1032, may be arranged to support a virtual machine, as will be appreciated by those skilled in the art.
One example of a virtual machine that is supported on computer system 1030 will be 2o described below with reference to Figure 6. As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU 1032, while RAM is used typically to transfer data and instructions in a bi-directional manner. CPU
1032 may generally include any number of processors. Both primary storage devices 1034, 1036 may include any suitable computer-readable media. A secondary storage 25 medium 1038, which is typically a mass memory device, is also coupled bi-directionally to CPU 1032 and provides additional data storage capacity. The mass memory device 1038 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, mass memory device 1038 is a storage medium such as a hard disk or a tape which is generally 3o slower than primary storage devices 1034, 1036. Mass memory storage device may take the form of a magnetic or paper tape reader or some other well-known device. It will be appreciated that the information retained within the mass memory device 1038, may, in appropriate cases, be incorporated in standard fashion as part of RAM 1036 as virtual memory. A specific primary storage device 1034 such as a CD-ROM may also pass data uni-directionally to the CPU 1032.
CPU 1032 is also coupled to one or more input/output devices 1040 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU
optionally may be coupled to a computer or telecommunications network, e.g., a local 1 o area network, an Internet network or an intranet network, using a network connection as shown generally at 1012. With such a network connection, it is contemplated that the CPU 1032 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using CPU 1032, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.
As previously mentioned, a virtual machine may execute on computer system 1030. Figure 6 is a diagrammatic representation of a virtual machine which is supported by computer system 1030 of Figure 5, and is suitable for implementing the present invention. When a computer program, e.g., a computer program written in the JavaTM programming language developed by Sun Microsystems of Palo Alto, California, is executed, source code 1110 is provided to a compiler 1120 within a compile-time environment 1105. Compiler 1120 translates source code 1110 into byte codes 1130. In general, source code 1110 is translated into byte codes 1130 at the time source code 1110 is created by a software developer.
3o Byte codes 1130 may generally be reproduced, downloaded, or otherwise distributed through a network, e.g., network 1012 of Figure 5, or stored on a storage device such as primary storage 1034 of Figure 5. In the described embodiment, byte codes 1130 are platform independent. That is, byte codes 1130 may be executed on substantially any computer system that is running a suitable virtual machine 1140. By way of example, in a JavaTM environment, byte codes 1130 may be executed on a computer system that is running a JavaTM virtual machine.
Byte codes 1130 are provided to a runtime environment 1135 which includes virtual machine 1140. Runtime environment 1135 may generally be executed using a processor such as CPU 1032 of Figure 5. Virtual machine 1140 includes a compiler 1142, an interpreter 1144, and a runtime system 1146. Byte codes 1130 may generally be provided either to compiler 1142 or interpreter 1144.
1o When byte codes 1130 are provided to compiler 1142, methods contained in byte codes 1130 are compiled into machine instructions, as described above. On the other hand, when byte codes 1130 are provided to interpreter 1144, byte codes are read into interpreter 1144 one byte code at a time. Interpreter 1144 then performs the operation defined by each byte code as each byte code is read into interpreter i 5 1144. In general, interpreter 1144 processes byte codes 1130 and performs operations associated with byte codes 1130 substantially continuously.
When a method is called from an operating system 1160, if it is determined that the method is to be invoked as an interpreted method, runtime system 1146 may 20 obtain the method from interpreter 1144. If, on the other hand, it is determined that the method is to be invoked as a compiled method, runtime system 1146 activates compiler 1142. Compiler 1142 then generates machine instructions from byte codes 1130, and executes the machine-language instructions. In general, the machine-language instructions are discarded when virtual machine 1140 terminates.
Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the invention. By way of example, steps involved with creating machine code from 3o source code that specifies explicit exception flow may be reordered, removed or added. In general, steps involved with the methods of the present invention may be reordered, removed, or added without departing from the spirit or the scope of the presentinvention.
While exception handling as a part of the normal control flow of a computer program has generally been described as being associated with a JavaT"' environment, it should be appreciated' that such exception handling may be implemented in substantially any suitable environment. By way of example, in lieu of an environment associated with a JavaTM virtual machine, environments associated with other virtual machine may be implemented. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims.
Claims (18)
1. A computer-implemented method for processing an exception in an object-based system, the computer-implemented method comprising:
obtaining source code, the source code including a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
creating a final internal representation of the source code, wherein creating the final internal representation includes removing a call associated with the exception check; and generating machine code, wherein the machine code is generated using the final internal representation.
obtaining source code, the source code including a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
creating a final internal representation of the source code, wherein creating the final internal representation includes removing a call associated with the exception check; and generating machine code, wherein the machine code is generated using the final internal representation.
2. A computer-implemented method as recited in claim 1 further including executing the machine code.
3. A computer-implemented method as recited in one of claims 1 and 2 wherein creating the final internal representation of the source code includes processing the exception check as a part of a control flow, the control flow being associated with the source code.
4. A computer-implemented method as recited in claim 3 wherein creating the final internal representation of the source code further includes optimizing the processing of the exception check.
5. A computer-implemented method as recited in any one of the preceding claims further including writing the source code, wherein writing the source code includes writing the code segment that is arranged to explicitly specify the instructions pertaining to the exception check.
6. A computer-implemented method as recited in any one of the preceding claims wherein creating the final internal representation includes:
calling a function associated with the exception check; and creating an object associated with the exception check in response to calling the function associated with the exception.
calling a function associated with the exception check; and creating an object associated with the exception check in response to calling the function associated with the exception.
7. A computer-implemented method as recited in claim 6 wherein creating the final internal representation further includes destroying the object associated with the exception check.
8. A computer-implemented method as recited in any one of the preceding claims wherein the exception check is one of a null pointer check and a range check.
9. A computer system for processing an exception, the computer system comprising:
a processor;
a source code generator, the source code generator being arranged to generate a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
an optimizer, the optimizer being arranged to create a final internal representation of the source code at least partially by removing a call associated with the exception check; and a machine code generator, the machine code generator being arranged to generate machine code using the final internal representation.
a processor;
a source code generator, the source code generator being arranged to generate a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
an optimizer, the optimizer being arranged to create a final internal representation of the source code at least partially by removing a call associated with the exception check; and a machine code generator, the machine code generator being arranged to generate machine code using the final internal representation.
10. A computer system according to claim 9 wherein the optimizer is further arranged to process the exception check as a part of a control flow, the control flow being associated with the source code.
11. A computer system according to one of claims 9 and 10 wherein the optimizer is further arranged to call a function associated with the exception check and to cause an object associated with the exception check to be created in response to the call to the function associated with the exception check.
12. A computer system according to any one of claims 9-11 wherein the optimizer is still further arranged to destroy the object associated with the exception check.
13. A computer program product for processing an exception in an object-based system, the computer program product comprising:
computer code for obtaining source code, the source code including a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
computer code for creating a final internal representation of the source code, wherein the computer code for creating the final internal representation includes computer code for removing a call associated with the exception check;
computer code for generating machine code using the final internal representation; and a computer-readable medium that stores the computer codes.
computer code for obtaining source code, the source code including a code segment that is arranged to explicitly specify instructions pertaining to an exception check;
computer code for creating a final internal representation of the source code, wherein the computer code for creating the final internal representation includes computer code for removing a call associated with the exception check;
computer code for generating machine code using the final internal representation; and a computer-readable medium that stores the computer codes.
14. A computer program product according to claim 13 wherein the computer-readable medium is one selected from the group consisting of a data signal embodied in a carrier wave, a CD-ROM, a hard disk, a floppy disk, a tape drive, and flash memory.
15. A computer-implemented method for creating a representation of source code, the source code including a plurality of code portions associated with exceptions, the computer-implemented method comprising:
obtaining the source code including the plurality of code portions associated with exceptions, wherein a first code portion selected from the plurality of code portions is nested within a second code portion selected from the plurality of code portions;
determining whether the first code portion is redundant with respect to the second code portion; and transforming the source code into an internal representation, wherein transforming the source code into an internal representation includes eliminating the first code portion from the source code when it is determined that the first code portion is redundant with respect to the second code portion.
obtaining the source code including the plurality of code portions associated with exceptions, wherein a first code portion selected from the plurality of code portions is nested within a second code portion selected from the plurality of code portions;
determining whether the first code portion is redundant with respect to the second code portion; and transforming the source code into an internal representation, wherein transforming the source code into an internal representation includes eliminating the first code portion from the source code when it is determined that the first code portion is redundant with respect to the second code portion.
16. A computer-implemented method as recited in claim 15 further including transforming the internal representation into machine code.
17. A computer-implemented method as recited in one of claims 15 and 16 wherein the first code portion and the second code portion each includes a determination of whether to throw a particular exception, and determining whether the first code portion is redundant with respect to the second code portion includes determining when the first code portion is arranged to be reached by a program control flow associated with the source code when the particular exception is not to be thrown.
18. A computer-implemented method as recited in claim 17 wherein when it is determined that the first code portion is arranged to be reached by the program control flow associated with the source code when the particular exception is not to be thrown, the first code portion is determined to be redundant with respect to the second code portion.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/298,354 US6363522B1 (en) | 1999-04-23 | 1999-04-23 | Method and apparatus for handling exceptions as normal control flow |
| US09/298,354 | 1999-04-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2306519A1 true CA2306519A1 (en) | 2000-10-23 |
Family
ID=23150143
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002306519A Abandoned CA2306519A1 (en) | 1999-04-23 | 2000-04-20 | Method and apparatus for handling exceptions as normal control flow |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6363522B1 (en) |
| EP (1) | EP1049011A3 (en) |
| JP (1) | JP2000347872A (en) |
| CN (1) | CN1197003C (en) |
| AU (1) | AU774192B2 (en) |
| CA (1) | CA2306519A1 (en) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7086066B2 (en) * | 2000-03-31 | 2006-08-01 | Schlumbergersema Telekom Gmbh & Co. Kg | System and method for exception handling |
| JP3974742B2 (en) * | 2000-04-14 | 2007-09-12 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Compile device, optimization method, and recording medium |
| US20020184566A1 (en) * | 2001-06-01 | 2002-12-05 | Michael Catherwood | Register pointer trap |
| CA2356018A1 (en) * | 2001-08-29 | 2003-02-28 | Ibm Canada Limited-Ibm Canada Limitee | Http connector |
| US20030135788A1 (en) * | 2002-01-11 | 2003-07-17 | Raj Prakash | Profile feedback assisted null check removal |
| US7685581B2 (en) | 2003-06-27 | 2010-03-23 | Microsoft Corporation | Type system for representing and checking consistency of heterogeneous program components during the process of compilation |
| US7146606B2 (en) | 2003-06-26 | 2006-12-05 | Microsoft Corporation | General purpose intermediate representation of software for software development tools |
| US7305666B2 (en) * | 2003-07-23 | 2007-12-04 | Microsoft Corporation | Description language for an extensible compiler and tools infrastructure |
| US7559050B2 (en) * | 2003-06-30 | 2009-07-07 | Microsoft Corporation | Generating software development tools via target architecture specification |
| US7707566B2 (en) * | 2003-06-26 | 2010-04-27 | Microsoft Corporation | Software development infrastructure |
| US7120898B2 (en) * | 2003-06-26 | 2006-10-10 | Microsoft Corporation | Intermediate representation for multiple exception handling models |
| US7788652B2 (en) * | 2003-06-27 | 2010-08-31 | Microsoft Corporation | Representing type information in a compiler and programming tools framework |
| US7669193B1 (en) * | 2003-09-25 | 2010-02-23 | Lantronix, Inc. | Program transformation using flow-sensitive type constraint analysis |
| GB2412192B (en) * | 2004-03-18 | 2007-08-29 | Advanced Risc Mach Ltd | Function calling mechanism |
| US7802080B2 (en) * | 2004-03-24 | 2010-09-21 | Arm Limited | Null exception handling |
| US20060005169A1 (en) * | 2004-06-30 | 2006-01-05 | International Business Machines Corporation | Software development system and method |
| JP4626963B2 (en) * | 2004-11-15 | 2011-02-09 | パラマウントベッド株式会社 | Bed with side rail |
| TWI283192B (en) * | 2004-12-21 | 2007-07-01 | Ind Tech Res Inst | A flat-plate type static dust-connecting device |
| US7539983B2 (en) * | 2005-01-14 | 2009-05-26 | Microsoft Corporation | Tool for processing software programs using modified live-ness definition |
| US7797690B2 (en) * | 2005-03-15 | 2010-09-14 | International Business Machines Corporation | System, method and program product to optimize code during run time |
| US8161470B2 (en) * | 2007-08-31 | 2012-04-17 | International Business Machines Corporation | Systems, methods, and computer products for automated injection of java bytecode instructions for java load time optimization via runtime checking with upcasts |
| US8250544B2 (en) * | 2008-03-05 | 2012-08-21 | Microsoft Corporation | Annotating exception information in a computer program |
| US8495606B2 (en) * | 2008-11-14 | 2013-07-23 | Oracle America, Inc. | Redundant exception handling code removal |
| US9052984B2 (en) * | 2009-02-26 | 2015-06-09 | International Business Machines Corporation | Exception declaration refactoring to reduce memory footprint |
| US8612928B2 (en) * | 2010-04-07 | 2013-12-17 | Microsoft Corporation | Generating exception-based component models from non-exception-based models |
| KR101962248B1 (en) * | 2012-03-16 | 2019-03-27 | 삼성전자주식회사 | Apparatus and method for supporting verification of reconfigurable processor |
| US10055209B2 (en) * | 2015-01-12 | 2018-08-21 | Red Hat, Inc. | Resource closing |
| CN110674622B (en) * | 2018-07-03 | 2022-12-20 | 百度在线网络技术（北京）有限公司 | Visual chart generation method and system, storage medium and electronic equipment |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4642765A (en) * | 1985-04-15 | 1987-02-10 | International Business Machines Corporation | Optimization of range checking |
| IL100990A (en) * | 1991-02-27 | 1995-10-31 | Digital Equipment Corp | Multilanguage optimizing compiler using templates in multiple pass code generation |
| IL100986A (en) * | 1991-02-27 | 1997-01-10 | Digital Equipment Corp | Method for compiling code |
| IL100987A (en) * | 1991-02-27 | 1995-10-31 | Digital Equipment Corp | Method and apparatus for compiling code |
| US5668999A (en) * | 1994-12-20 | 1997-09-16 | Sun Microsystems, Inc. | System and method for pre-verification of stack usage in bytecode program loops |
| US6185668B1 (en) * | 1995-12-21 | 2001-02-06 | Intergraph Corporation | Method and apparatus for speculative execution of instructions |
| US5875335A (en) * | 1996-09-30 | 1999-02-23 | Apple Computer, Inc. | Parameter marshaling techniques for dynamic object-oriented programming languages |
| US5838978A (en) * | 1996-10-09 | 1998-11-17 | Hewlett-Packard Company | System and method of using annotations to optimize dynamically translated code in the presence of signals |
| US5778233A (en) * | 1996-10-11 | 1998-07-07 | International Business Machines Corporation | Method and apparatus for enabling global compiler optimizations in the presence of exception handlers within a computer program |
| US5905895A (en) * | 1997-03-07 | 1999-05-18 | International Business Machines Corporation | Method and system for optimizing non-native bytecodes before bytecode interpretation |
| JPH1139169A (en) * | 1997-07-18 | 1999-02-12 | Toshiba Corp | Compiling method, compiler, exception handler and program storage medium |
| US6047125A (en) * | 1997-10-01 | 2000-04-04 | Sun Microsystems, Inc. | Garbage collection system for improved use of memory by removal of reference conflicts |
| US6128774A (en) * | 1997-10-28 | 2000-10-03 | Necula; George C. | Safe to execute verification of software |
| US6202204B1 (en) * | 1998-03-11 | 2001-03-13 | Intel Corporation | Comprehensive redundant load elimination for architectures supporting control and data speculation |
| US6131187A (en) * | 1998-08-17 | 2000-10-10 | International Business Machines Corporation | Method and system for translating exception handling semantics of a bytecode class file |
| US6202145B1 (en) * | 1998-12-14 | 2001-03-13 | International Business Machines Corporation | System and method for eliminating a ring transition while executing in protected mode |
-
1999
- 1999-04-23 US US09/298,354 patent/US6363522B1/en not_active Expired - Lifetime
-
2000
- 2000-04-20 AU AU28919/00A patent/AU774192B2/en not_active Expired
- 2000-04-20 CA CA002306519A patent/CA2306519A1/en not_active Abandoned
- 2000-04-24 JP JP2000122769A patent/JP2000347872A/en active Pending
- 2000-04-24 CN CNB001070207A patent/CN1197003C/en not_active Expired - Lifetime
- 2000-04-25 EP EP00303465A patent/EP1049011A3/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| CN1197003C (en) | 2005-04-13 |
| EP1049011A2 (en) | 2000-11-02 |
| EP1049011A3 (en) | 2007-02-28 |
| US6363522B1 (en) | 2002-03-26 |
| CN1271890A (en) | 2000-11-01 |
| AU774192B2 (en) | 2004-06-17 |
| JP2000347872A (en) | 2000-12-15 |
| AU2891900A (en) | 2000-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6363522B1 (en) | Method and apparatus for handling exceptions as normal control flow | |
| US6553565B2 (en) | Method and apparatus for debugging optimized code | |
| EP4099153B1 (en) | Extending a virtual machine instruction set architecture | |
| US6408433B1 (en) | Method and apparatus for building calling convention prolog and epilog code using a register allocator | |
| CN1119756C (en) | Method and system for performing static initialization | |
| EP1049010A2 (en) | Method and apparatus for generating a platform-specific compiler | |
| JPH11327916A (en) | Cost reduction technique for dynamic class initialization check in already compiled code | |
| JP2000347876A (en) | Method and device for stack slot allocation | |
| CN100378657C (en) | Method and device for improving call speed of JAVA method | |
| US7020874B2 (en) | Techniques for loading class files into virtual machines | |
| EP0945790B1 (en) | Method and apparatus for implementing fast subclass and subtype checks | |
| US6901591B1 (en) | Frameworks for invoking methods in virtual machines | |
| US6421824B1 (en) | Method and apparatus for producing a sparse interference graph | |
| US7065747B2 (en) | Identifying references to objects during bytecode verification | |
| US6978448B1 (en) | Method and apparatus for rewriting bytecodes to minimize runtime checks | |
| EP1046985A2 (en) | File portability techniques | |
| US20020199169A1 (en) | Representation of Java data types in virtual machines | |
| KR100649799B1 (en) | Method and apparatus for implementing fast subclass and subtype checks | |
| Gough | The DCode Intermediate Representation: Reference Manual and Report |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |