Optimizing parameter passing

[0002] This invention relates to the run-time efficiency of computer programs and, more specifically, to a method for optimizing parameter passing.

[0003] An important consideration in many computer programs and programming languages is performance. Speed and correctness are examples of performance metrics, and are critical to the viability of computation intensive computer programs.

[0004] The quest for greater run-time speeds has often focussed on ways that information or data and data structures can be accessed and manipulated. Often, computer programs include routines that carry out well-defined operations on data specified by parameters. As used herein, the term “routine” refers to functions, procedures, methods and/or subroutines. To transfer control to a routine, a call is made to the routine. For the purposes of explanation, the portion of code that makes a call to a routine will be referred to as the “calling routine”, while the portion of the code thus called is the “called routine”. Typically, parameters are provided from the calling routine to the called routine as input for each call.

[0005] The act of passing parameter values to a called routine is known as “parameter passing”. Two common methods of parameter passing are “call by value”, and “call by reference”. The following definitions aid in explaining parameter passing. A “formal parameter” is a parameter value stored in a storage location that is used by the called routine. An “actual parameter” is a parameter value stored in a storage location used by the calling routine. From the perspective of the calling routine, the “actual parameter” is passed to and/or received from the called routine. From the perspective of the called routine, the “formal parameter” is received from and/or passed to the calling routine.

[0006] In the case of “call by value”, the actual parameter and the corresponding formal parameter are stored in separate storage locations. Specifically, the value of the actual parameter in the calling routine is copied to a separate storage allocated for holding the formal parameter in the called routine. Therefore, any changes made to the formal parameters of the routine modify only the copy of the actual parameter. Only upon successful completion of execution of the called routine, the modified value of the formal parameter is copied back to the actual parameter. Thus, when the called routine fails with an unanticipated error (“unhandled exception”), the modified value of the formal parameter is not copied back to the actual parameter. This ensures that the actual parameter remains uncorrupted by any exception occurring during execution of the called routine. Note that for anticipated errors (handled exceptions), it is assumed that the proper recovery mechanism is employed.

[0007] However, the disadvantage of “call by value” parameter passing is that it is inefficient. As explained above, in executing a call, two copy operations are performed for each parameter for “call by value”. The first copy is performed when the value of the actual parameter is copied to a separate storage allocated for holding the formal parameter of the routine before execution of the routine (copy-in). The second copy is performed when the modified value of the formal parameter of the called routine is copied back to the actual parameter upon successful completion of execution of the called routine (copy-out). Thus, the copy-in and copy-out transactions incurred in “call by value” parameter passing are inefficient. This is of particular concern in database systems where applications manipulate large volumes of data and where a parameter can comprise a very large data structure, such as a large record, or large array.

[0008] In the case of “call by reference”, the same storage location is used for both the actual and formal parameters. Specifically, the address of the actual parameter of the calling routine is passed to the called routine. Any changes made by the called routine to the formal parameter directly modify the actual parameter. There is no copy-in and copy-out of the parameters. Because no copies of the values of the parameters are required in “call by reference” parameter passing, it is more efficient than “call by value” parameter passing. However, there are at least two disadvantages to “call by reference” parameter passing.

[0009] One obvious disadvantage to “call by reference” parameter passing is that the routine directly modifies the actual parameter as explained above. Thus, when the called routine fails due to an unhandled exception, whatever undesirable modifications made by the called routine are made directly to the actual parameters.

[0010] Another disadvantage to “call by reference” parameter passing is in the context of aliases. Two parameters in a program are said to be aliased if they both point to the same memory location. This can cause unintended results. For example, consider a procedure that has two parameters. Suppose the same parameter is passed twice in the same call to the procedure using “call by reference” as illustrated in the following pseudocode, interspersed with explanatory comments denoted by the prefix, “ - - - ”:

[0011] main ( )

[0012] n number;

[0013] begin

[0014] n:=10;

[0015] proc (n, n); - - - call to the routine proc end;

[0016] Assume that the routine proc is as follows:

[0017] proc (p1 number, p2 number) is

[0018] begin

[0019] p1:=5;

[0020] print (p2);

[0021] end;

[0022] The print statement in the above routine will produce the value 5 if p1 and p2 are passed using “call by reference”. Both p1 and p2 point to the same memory location, i.e. the memory location of the actual parameter, n. The first assignment,

[0023] p1:=5;

[0024] would modify the value of p2 as well. Clearly, this produces an unintended result.

[0025] Note that if the p1 and p2 were passed to routine proc using “call by value” parameter passing, the print statement would produce the value 10. Even though the same variable n was passed twice to the routine proc as actual parameters, two separate copies of the actual parameter, one bound to p1 and the other bound to p2, were made before execution of routine proc. Thus, the following assignment would only modify the copy of the actual parameter that is bound to p1.

[0026] p1:=5;

[0027] However, the copy of the actual parameter that is bound to p2 remained intact. Thus, the following print statement would produce the value 10.

[0028] print (p2);

[0029] To summarize, “call by value” parameter passing has the advantage of clean semantics in the context of exception handling and aliases. However, this advantage comes at the expense of performance. Whereas “call by reference” parameter passing has the advantage of good performance but may produce unintended results in the context of aliases. “Call by reference” parameter passing may also cause corruption of actual parameters due to unhandled exceptions.

[0030] Alias detection and prevention is a well-researched problem. A number of techniques have been suggested in the literature. An appropriate technique can be used in conjunction with this invention to determine the presence of aliasing among parameters as well as among global variables and subprogram parameters.

[0031] Based on the foregoing, there is a need for a method or mechanism to take advantage of better performance provided by “call by reference” parameter passing while obviating unintended results in the context of aliases and corruption of actual parameters due to unhandled exceptions.

[0032] The foregoing needs are addressed by the present invention, which comprises, in one aspect, a method and system for optimizing the passing of a parameter to a routine. It is determined if any parameters are aliased in a call to a called routine. In the absence of aliases, calling routines pass parameters to called routines using “call by reference”. Recovery mechanisms are provided, when appropriate, when unhandled exceptions occur during execution of the called routines.

[0033] According to one aspect of the invention, a recovery mechanism includes encapsulating the called routine and call statement block with a “catch-all” exception handler. Another aspect of the invention includes responding to an otherwise unhandled exception by restoring the actual parameter using a stored copy of the actual parameter. In one embodiment, the restoration is performed by making a handle (pointer) point to the copy of the actual parameter that was made before execution of the called routine.

[0034] Still other objects and advantages of the present invention will become readily apparent from the following detailed description, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawing and description are to be regarded as illustrative in nature, and not as restrictive.

[0035] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

[0036] FIG. 1A is a flowchart that illustrates a method of parameter passing using copies of actual parameters;

[0037] FIG. 1B is a flowchart that illustrates a method of parameter passing during run-time;

[0038] FIG. 2 is a block diagram that illustrates a method of parameter passing using handles;

[0039] FIG. 3 is a flowchart that illustrates a method of parameter passing without using copies of actual parameters; and

[0040] FIG. 4 illustrates a computer system on which embodiments of the present invention may be implemented.

[0041] A method and system are described for optimizing parameter passing. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0042] In one embodiment of the invention, “call by reference” is the preferred method for parameter passing as long as there are no aliased parameters in a call to a called routine. As explained earlier, “call by reference” parameter passing avoids the overhead of “call by value” parameter passing because there is no copy-in and copy-out of the actual parameter. However, the actual parameter may be corrupted if an unhandled exception occurs during execution of the called routine. To mitigate the problem of an unhandled exception, a mechanism is provided to ensure that the actual parameter is restored to its original value by making one copy of the actual parameter before execution of the called routine. Either the calling routine or the called routine makes the copy of the actual parameter before execution of the called routine. If an unhandled exception occurs in the called routine, the actual parameter is restored to its original value by replacing it with the copy that was made before execution of the called routine. If the called routine successfully executes, the copy is discarded. Thus, in the case where the routine executes successfully, the technique of making a copy of the actual parameter before execution of the called routine but still having the called routine operate on the actual parameter results in a 50% savings in overhead as compared to “call by value” parameter passing. Even when an unhandled exception occurs during execution of the called routine, the total overhead, including the overhead associated with restoring the actual parameter, is no more than the total overhead incurred in “call by value” parameter passing.

[0043] According to another aspect of the invention, the overhead associated with restoring the actual parameter in the event of an unhandled exception can be reduced. This is accomplished by not only making a copy of the actual parameter before execution of the called routine but also making a handle to the copy of the actual parameter. A handle is a pointer to a resource. Before execution of the called routine, a copy of the actual parameter is made and a temporary handle is created to point to the storage location that is storing the copy of the actual parameter. As before, a 50% savings in overhead is realized if the called routine executes successfully. However, unlike the previous case, if an unhandled exception occurs during execution of the called routine, the actual parameter is restored while incurring minimal overhead by simply replacing the handle of the actual parameter (used by the calling routine to access the actual parameter) with the handle that points to the copy of the actual parameter. This assumes that the calling routine accesses the actual parameter using a handle. This technique of copying a handle is especially useful when large data structures are involved. Restoring large data structures by copying an uncorrupted version over the corrupted one can significantly impact performance. Merely replacing a handle, on the other hand, incurs significantly less overhead.

[0044] According to yet another aspect of the invention, a 100% savings in overhead can be realized when certain conditions are satisfied, by using “call by reference” parameter passing and neither making a copy of the actual parameter nor making a handle for the copy of the actual parameter, as part of the recovery mechanism if an unhandled exception occurs in the called routine.

[0045] Specifically, if it is determined that neither the calling routine nor the called routine contain any exception handlers, then “call by reference” parameter passing is used without the expense of making any copy of the actual parameter or making a handle for the copy of the actual parameter. Often, routines do not contain any exception handling in order to allow the exception to propagate upward to a calling routine at a higher level in the call stack, and which has sufficient context information for deciding the appropriate recovery mechanism. Since the exception, if any, will be handled by a calling routine at a higher level in the call stack, there is no need to create another recovery mechanism at the lower level calling routine. For example, assume routine A calls routine B that calls routine C. If neither B nor C contain any exception handlers because A is better equipped to handle an exception, then, if certain conditions are satisfied, parameters are passed from B to C using “call by reference” parameter passing, and without the expense of making any copy of the actual parameter or making a handle for the copy of the actual parameter. The conditions that must be satisfied for “call by reference” parameter passing to be used under these circumstances are that the parameters passed from B to C are either local to B or, if they are not local to B, then they were passed from A to B using “call by value” parameter passing.

[0046] In another aspect of the invention, if it is determined that the called routine contains a “catch-all” exception handler, then “call by reference” parameter passing is used without the expense of making any copy of the actual parameter or making a handle for the copy of the actual parameter. A “catch-all” exception handler in the called routine will ensure that there are no unhandled exceptions during the execution of the called routine. For the purpose of simplification, it is assumed that there are no exceptions raised during execution of the exception handler itself. Thus, there will always be a recovery mechanism for preserving the integrity of any actual parameter that was passed to the called routine.

[0047] In yet another aspect of the invention, if it is determined that the set of exception handlers in the called routine is equal to or a superset of the set of exception handlers in the calling routine, then “call by reference” parameter passing is used without the expense of making any copy of the actual parameter. Here it is also assumed that there are no exceptions raised during execution of the exception handler. To illustrate, again assume that routine A calls routine B that calls routine C. Assume also that C's set of exception handlers is equal to or a superset of the set of exception handlers in B. B can pass any of its local variables to C using “call by reference” without the expense of making any copy of the value the parameters because B's local variables are not visible to A and therefore do not affect A. If an unhandled exception occurs during the execution of C, then the earliest that the exception can be handled is at A because B's set of exception handlers is a subset of C's set of exception handlers. Thus, A can deploy the appropriate recovery mechanism and is unaffected by B's now corrupted local variables. For this same reason, B can also pass to C, using “call by reference” without the expense of making any copies, all variables that are not local to B but that were passed to B from A using “call by value” parameter passing. When the unhandled exception occurring in C propagates up to A, the parameters that A passed to B will be intact because they were passed to B using “call by value” parameter passing.

[0048] FIG. 1A is a flowchart illustrating a method to pass parameters for a particular call made from a calling routine to a called routine so as to achieve 50% savings in overhead when no unhandled exceptions occur as compared to conventional “call by value” parameter passing techniques. The method in FIG. 1A is to be viewed in the context of a compiler generating executable code to implement an embodiment of the invention. However, the techniques described herein are not limited to the context of a compiler. For example, an embodiment of the invention is described in the context of a pre-compiler as well, as detailed below under the subheading, “Pre-compiler Implementation”.

[0049] Returning to the context of a compiler, assume that the compiler would generate executable code in the manner that it normally would when compiling a computer program. However, in order to implement an embodiment of the invention, the compiler would have to perform some additional steps. FIG. 1A describes such additional steps and in no way suggests that these are the only steps performed by the compiler. In FIG. 1A, at block 100, a compiler determines, for the particular call, if the calling routine is passing one or more aliased parameters. Recall that if the calling routine passes the same parameter more than once in the same call to the called routine, it is said to be passing aliased parameters. Another example of aliased parameters is when two different parameters are passed to a called routine but the parameters point to the same memory location. Also, a parameter that is passed to a called routine is said to be aliased if it points to the same memory location as another variable that is visible to the called routine (e.g. a global variable). If aliased parameters are passed in a call to a called routine, then at block 108, the compiler generates code for “call by value”. When a parameter is aliased, “call by value” passing is necessary to preserve the correct alias semantics inherent in “call by value” parameter passing, and no savings in overhead can be realized for that parameter.

[0050] If the call does not include aliased parameters, then at block 102, for that particular call, the compiler generates executable code to pass the parameters from the calling routine to the called routine using “call by reference” parameter passing. At block 104, the compiler generates executable code that performs “catch-all” exception handling to catch any unhandled exception occurring in the called routine. This is achieved by generating executable code that has the effect of wrapping the call statement to the called routine with a “catch-all” exception handler. At block 106, the compiler generates executable code that makes a copy of each actual parameter being passed to the called routine using “call by reference”. The generated executable code causes these copies to be made before execution of the called routine. At block 110, the compiler generates code in the “catch-all” exception handler to restore the values of the actual parameters from the aforementioned copies and to re-raise the exception.

[0051] FIG. 1B is a flowchart illustrating what happens during run-time execution of the code generated by the process of FIG. 1A. At block 120 of FIG. 1B, a copy is made of each actual parameter to be passed to the called routine using “call by reference”. At block 122, the parameters are passed from the calling routine to the called routine using “call by reference. At block 124, it is determined if the called routine failed with an unhandled exception during execution. If the called routine executes successfully, then at block 126 the copies of the actual parameters are discarded. Otherwise, at block 128, the actual parameters are restored to their original value before execution of the called routine by overwriting the corrupted parameters with the copies, made before execution of the called routine, of the actual parameters.

[0052] For purposes of explanation, an embodiment of the invention has been described in the context of a compiler generating executable code that implements a particular call. However, the techniques described herein are not limited to that context. For example, a pre-compiler may be used to generate source code to wrap the called routine and the call statement to the called routine with a “catch-all” exception handler, as well as generating code to make of a copy of each actual parameter being passed using “call by reference”. A pre-compiler is a computer program that automatically adds, deletes or otherwise alters the lines of source code of a given computer program. Whereas a compiler converts source code into executable code, a pre-compiler converts source code into modified source code. In the case of using a pre-compiler, the pre-compiler would use the appropriate “call by reference” syntax for parameters that are to be passed by “call by reference” to a called routine. The pre-compiler would also add the appropriate lines of source code to (1) to make copies of actual parameters to be passed to the called routine before execution of the called routine, and (2) create a “catch-all” exception handler for the called routine that restores the actual parameters in the event of an unhandled exception.

[0053] A pre-compiler implementation of the method in FIG. 1A can be illustrated by the following pseudocode. Within the pseudocode are interspersed explanatory comments denoted by the prefix, “ - - - ”:

[0054] For the purpose of explanation, assume that the calling routine contains the following source code:

[0055] main ( )

[0056] parm1 number;

[0057] parm2 char( . . . );

[0058] begin

[0059] proc (parm1, parm2); - - - call statement

[0060] end;

[0061] Further, assume that the called routine is as follows:

[0062] proc (n number, v char) is

[0063] begin

[0064] . . .

[0065] end;

[0066] The calling routine code includes a call to the routine “proc” that passes two parameters. The actual parameters passed in this call are “parm1” and “parm2”. The calling routine also includes code that declares the type of these actual parameters.

[0067] At step 100, the pre-compiler encounters the call statement “proc (parm1, parm2)” and determines whether the call is passing any aliased parameters. In the present example, the two parameters passed to “proc” are not aliased, so control passes to step 102. At step 102, the pre-compiler modifies the source code as needed to specify that “call by reference” parameter passing should be used to pass parm1 and parm2 to proc. The actual modification performed at this point will vary from implementation to implementation based on the syntax of the source code language. For example, call by reference parameter passing may involve adding an “&” before the actual parameters in the call statement, resulting in the modified call statement of “proc (&parm1, &parm2)”.

[0068] At step 106, the pre-compiler generates source code that declares temporary variables that correspond to the actual parameters, and causes the value of each actual parameter to be stored in its corresponding temporary variable. This code is placed before the call statement in the called routine. After this code is generated, the source code for the calling routine may appear as follows:

[0069] main ( )

[0070] temp1 number;

[0071] temp2 char( . . . );

[0072] parm1 number;

[0073] parm2 char( . . . );

[0074] begin

[0075] temp1:=parm1 - - - make copy of actual parameter

[0076] temp2:=parm2 - - - make copy of actual parameter

[0077] proc (&parm1, &parm2);—both parm1 and parm2 are passed

[0078] - - - using call by reference

[0079] end;

[0080] Next, the pre-compiler generates code that will discard the copy of each actual parameter if the called routine executes successfully. The pre-compiler also generates code that has the effect of wrapping the call statement with a “catch-all” exception handler. After these steps are performed, the pseudo code of the calling routine may contain additional lines of code as follows.

[0081] main ( )

[0082] . . .

[0083] begin

[0084] temp1:=parm1 - - - make copy of actual parameter

[0085] temp2:=parm2 - - - make copy of actual parameter

[0086] proc (&parm1, &parm2); - - - both parm1 and parm2 are passed

[0087] - - - using call by reference

[0088] - - - proc has completed successfully. Deallocate memory for temp1 & temp2

[0089] free memory for temp1 & temp2;

[0090] exception

[0091] when others then - - - when others represents a “catch-all” exception

[0092] parm1:=temp1;

[0093] parm2:temp2;

[0094] raise; - - - re-raise the exception

[0095] end;

[0096] During run-time, temp1 and temp2, the temporary copies of the actual parameters, parm1 and parm2, are created. The copies are made before the execution of the routine proc. If proc executes successfully, then temp1 and temp2 are discarded. However, if proc fails with an unhandled exception, then the “catch all” exception handler, “when others”, wrapped around the call block restores the actual parameters, parm1 and parm2, to their original value by overwriting the values of parm1 and parm2 with the values stored in temp1 and temp2 respectively.

[0097] Using the technique described above, the copy-out overhead associated with call-by-value parameter passing is avoided when execution of the called routine does not result in an unhandled exception. However, the copy-out overhead is still incurred when execution of the called routine does result in an unhandled exception. In the example given above, that overhead is embodied in the statements:

[0098] parm1:=temp1;

[0099] parm2:=temp2;

[0100] which are executed upon encountering an otherwise unhandled exception. According to one embodiment, a mechanism is provided for reducing the copy-out overhead, even in the case of an unhandled exception, when the calling routine uses a handle to access the actual parameters.

[0101] FIG. 2 is a block diagram illustrating the use of temporary handles to preserve the 50% savings in overhead when an unhandled exception occurs. In FIG. 2, assume that routine 202 is the calling routine and routine 208 is the called routine. The calling routine 202 maintains a parameter handle 204 that points to the actual parameter 206. All access to actual parameter 206 by the calling routine 202 is made through handle 204. The dotted arrows in FIG. 2, numbered 1 to 4, represent a sequence of actions as explained below. The solid arrows are pointers.

[0102] In the call to called routine 208, an actual parameter is passed by reference by passing the value of parameter handle 204 (indicated by dotted arrow (1)) to the called routine 208. Before execution of called routine 208, a copy 212 of the actual parameter 206 is made (indicated by dotted arrow (2)). Next, a temporary handle 210 is created to point to the copy 212 of actual parameter 206 (indicated by dotted arrow (3)).

[0103] If the routine 208 fails with an unhandled exception, simply overwriting parameter handle 204 with the temporary handle 210 (indicated by dotted arrow (4)) restores the actual parameter 206. The actual parameter 206 is restored while incurring minimal overhead by simply replacing its handle with the temporary handle 210 that points to the copy, made before execution of the called routine 208, of the actual parameter 206. Restoring large data structures by copying an uncorrupted version of the data structure over the corrupted one can significantly impact performance. Merely replacing a handle, on the other hand, incurs significantly less overhead. By overwriting parameter handle 204 with the temporary handle 210, the actual parameter's handle will then point to the uncorrupted copy 212 of the actual parameter.

[0104] The following pseudocode serves to further illustrate the use of temporary handles to preserve the 50% savings in overhead when an unhandled exception occurs. Within the pseudocode are interspersed explanatory comments denoted by the prefix, “ - - - ”.

[0105] Assume that the compiler has determined that the calling routine is not passing aliased parameters to the called routine, and the compiler has generated code to use “call by reference” parameter passing for parameters n and v. Further, assume that the called routine is as follows:

[0106] proc (n number, v char) is

[0107] begin

[0108] . . .

[0109] end;

[0110] Next, assume that the calling routine is as follows.

[0111] main ( )

[0112] temp1 number;

[0113] temp2 char( . . . );

[0114] parm1 number;

[0115] parm2 char( . . . );

[0116] begin

[0117] proc (parm1, parm2); - - - call statement

[0118] end,

[0119] The compiler generates executable code that causes a copy of each actual parameter before the executing the call statement, which is a call to the called routine. The compiler also generates executable code that causes a temporary handle to be made for each copy of each actual parameter to be passed using “call by reference” to the called routine. Next, the compiler generates executable code that will discard the copy of each actual parameter as well as their respective temporary handles if the called routine executes successfully. The compiler then generates executable code that has the effect of wrapping the call statement with a “catch-all” exception handler. If a pre-compiler is used, the pseudo code of the calling routine may contain additional lines of code as follows.

[0120] main ( )

[0121] . . .

[0122] begin

[0123] temp1:=parm1 - - - make copy of actual parameter

[0124] temp2:=parm2 - - - make copy of actual parameter

[0125] proc (parm1, parm2); - - - call statement; both parm1 and parm2 are passed

[0126] - - - using call by reference

[0127] - - - proc has completed successfully. Deallocate memory for temp1 & temp2

[0128] free memory for temp1 & temp2;

[0129] exception

[0130] when others then - - - when others represents a “catch-all” exception

[0131] free memory for parm1 & parm2;

[0132] overwrite the handles of parm1 & parm2 with the handles of temp1 & temp2 respectively;

[0133] - - - re-raise the exception;

[0134] raise;

[0135] end;

[0136] During run-time, temp1 and temp2, the temporary copies of the actual parameters, parm1 and parm2, are created. The copies are made before the execution of the routine proc. If proc executes successfully, then temp1 and temp2 are discarded. However, if proc fails with an unhandled exception, then the “catch all” exception handler wrapped around the call block overwrites the handles of parm1 and parm2 with the values of the handles for temp1 and temp2 respectively.

[0137] In the techniques described above, temporary variables were used to store parameter values so that the parameter values could be restored in the case of an unhandled exception. This use of temporary variables serves as a safety mechanism to ensure that call-by-value semantics are achieved. However, this safety mechanism incurs the copy-in overhead of copying the actual parameter values into the temporary variables prior to executing the call. According to one aspect of the invention, techniques are employed to detect conditions in which the safety mechanism is not needed. If it is detected that the safety mechanism is not needed for the call, the safety mechanism code is not generated for making the call. Thus, executing the call does not generate the overhead associated with the safety mechanism.

[0138] FIG. 3 is a flowchart that illustrates steps of generating code for a call, where “call by reference” is used to pass a parameter to the called routine without the expense of making a copy of the actual parameter, or restoring the actual parameter in the case of an unhandled exception.

[0139] At block 300 of FIG. 3, the compiler first determines if there are any parameters that are aliased in the call to the called routine. If aliased parameters are passed in the call, then at block 304, the compiler generates code for “call by value” parameter passing. The “call by value” code preserves the correct alias semantics inherent in “call by value” parameter passing, but no savings in overhead can be realized.

[0140] If the call does not include an aliased variable, then at block 302, the compiler determines what set of exception handlers the calling routine and called routine possess. At block 306, it is determined whether either the calling routine or the called routine possess any exception handlers. If neither the calling routine nor the called routine possess any exception handlers, then control passes to block 322.

[0141] At block 322, the compiler generates executable code to pass parameters using “call by reference” parameter passing without generating executable code to (1) make a copy of the actual parameter before execution of the called routine, and (2) make a handle for the copy of the actual parameter. By neither making a copy, during run-time, of the actual parameter, nor making a handle for said copy, 100% savings in overhead is realized over that of “call by value” parameter passing. In such a case, any exception propagates upward to a calling routine at a higher level in the call stack, and which has sufficient context information for deciding the appropriate recovery mechanism.

[0142] If at block 306, it is determined that either the calling routine or the called routine contain exception handlers, then control passes to block 308. At block 308, it is determined if the called routine contains a “catch-all” exception handler. If the called routine contains a “catch-all” exception handler, then control passes to block 322 (see above). Otherwise, at block 310, it is determined if the called routine's set of exception handlers is a superset of the calling routine's set of exception handlers. If it is determined that the called routine's set of exception handlers is not a superset of the calling routine's set of exception handlers, then control passes to block 316.

[0143] At block 316, the compiler generates executable code to pass the parameters from the particular calling routine to the called routine using “call by reference” parameter passing. At block 318, the compiler generates executable code that performs “catch-all” exception handling to catch any unhandled exception when control is returned to the calling routine. This is achieved by generating executable code that has the effect of wrapping the call statement to the called routine with a “catch-all” exception handler.

[0144] At block 320, the compiler generates executable code that makes a copy of each actual parameters being passed to the called routine using “call by reference”. The generated executable code causes these copies to be made before execution of the called routine. If the actual parameter maintains a handle, the compiler also generates code to make a handle for copies of the actual parameters if the actual parameters are large data structures. For purposes of explanation, causing the wrapping of the called routine and the call statement to the called routine with a “catch-all” exception handler, as well as causing the making of a copy of each actual parameter being passed using “call by reference” can be alternatively performed by a pre-compiler. In this case, the pre-compiler would use the appropriate “call by reference” syntax for parameters that are to be passed by “call by reference” to a called routine. The pre-compiler would also add the appropriate lines of source code to the calling routine that is passing parameters to the called routine using “call by reference”, such that the resulting executable code will make copies of actual parameters to be passed to the called routine before execution of the called routine, as well as cause the wrapping of the called routine and the call statement to the called routine with a “catch-all” exception handler. Control then passes to block 321 where either compiler or the pre-compiler generates code to raise again the exception.

[0145] If at block 310, it is determined that the called subroutine's set of exception handlers is a superset of the calling routine's set of exception handlers, then control passes to block 312. At block 312, it is further determined if the actual parameter being passed to the called routine is local to the calling routine. If the actual parameter being passed to the called routine from the calling routine is local to the calling routine, then at block 322, the compiler or pre-compiler generates code to cause “call by reference” parameter passing without the expense of either making copies of actual parameters or making handles to point to the copies.

[0146] Otherwise, if the actual parameter being passed to the called routine is not local to the calling routine, then at block 314, it is determined if the actual parameter being passed from the calling routine to the called routine was initially passed using “call by value” to the calling routine from another routine that is higher up in the call stack. If it is determined that the actual parameter being passed from the calling routine to the called routine was initially passed using “call by value” to the calling routine from another routine that is higher up in the call stack, then control passes to block 322 explained above. Otherwise, control passes to block 316 explained above.

[0147] FIG. 4 is a block diagram that illustrates a computer system 400 upon which an embodiment of the invention may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a processor 404 coupled with bus 402 for processing information. Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Computer system 400 further includes a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk or optical disk, is provided and coupled to bus 402 for storing information and instructions.

[0148] Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

[0149] The invention is related to the use of computer system 400 for parameter passing. According to one embodiment of the invention, parameter passing is provided by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another computer-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

[0150] The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0151] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0152] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.

[0153] Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0154] Network link 420 typically provides data communication through one or more networks to other data devices. For example, network link 420 may provide a connection through local network 422 to a host computer 424 or to data equipment operated by an Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 420 and through communication interface 418, which carry the digital data to and from computer system 400, are exemplary forms of carrier waves transporting the information.

[0155] Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418. In accordance with the invention, one such downloaded application provides for parameter passing as described herein.

[0156] The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution. In this manner, computer system 400 may obtain application code in the form of a carrier wave.

[0157] In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.