Computer-implemented method, computer system, and computer program for monitoring stack usage (Monitoring stack memory usage for program optimization)

Abstract

To solve the problem in which: conventional techniques to measure stack usage are not feasible in customer production environments.SOLUTION: A computer system determines stack usage. An intercept function is executed to store a stack marker in a stack, wherein the intercept function is invoked when a program enters or exits each function of a plurality of functions of the program. A plurality of stack markers are identified in the stack and a memory address is determined for each stack marker during execution of the program to obtain a plurality of memory addresses. The plurality of memory addresses are analyzed to identify a particular memory address associated with a greatest stack depth. A stack usage of the program is determined based on the greatest stack depth. Embodiments of the present invention further include a method and program product for determining stack usage in substantially the same manner described above.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate to stack-based memory allocation, and more particularly to monitoring the amount of stack memory used by a program and optimizing the program accordingly. [Background technology]

[0002] A stack is a specific memory area in a program where data is managed in a first-in, last-out manner by adding data to the stack when the program enters a function and removing the data when the program exits the function. The stack is often used to store fixed-length variables that are local to the currently active function. The stack may also be consumed by caller arguments, local variables, register save areas, return addresses, saved stack pointers, alignment padding, and / or other data, depending on the compiler and calling convention being used.

[0003] The amount of stack a program will require may not be known in advance, but can be determined experimentally using various techniques. Generally, programmers attempt to allocate enough stack for the program's requirements without allocating an excessive amount of stack to avoid unnecessary consumption of computing resources and ensure that the program will execute properly. Summary of the Invention [Problem to be solved by the invention]

[0004] Conventional techniques for measuring stack usage are not feasible in a customer production environment.

[0005] According to one embodiment of the present invention, a computer system determines stack usage. An intercept function is executed to store a stack marker on the stack, and the intercept function is called as the program enters or exits each of a plurality of functions of the program. A plurality of stack markers are identified in the stack, and a memory address is determined for each stack marker during execution of the program to obtain a plurality of memory addresses. The plurality of memory addresses are analyzed to identify a particular memory address associated with a maximum stack depth. The stack usage of the program is determined based on the maximum stack depth. Embodiments of the present invention further include methods and program products for determining stack usage in substantially the same manner as described above. [Brief explanation of the drawings]

[0006] Generally, like reference numbers in the various figures are used to designate like components.

[0007] [Figure 1] FIG. 1 is a block diagram illustrating a computing environment for determining stack usage according to one embodiment of the present invention.

[0008] [Figure 2] FIG. 2 is a block diagram illustrating a program at runtime according to an embodiment of the present invention.

[0009] [Figure 3] FIG. 2 is a block diagram illustrating a stack according to one embodiment of the present invention.

[0010] [Figure 4] FIG. 2 is a block diagram illustrating the collection of stack usage data according to one embodiment of the present invention.

[0011] [Figure 5] 1 is a flowchart illustrating a method for determining stack usage according to one embodiment of the present invention.

[0012] [Figure 6] 1 is a flowchart illustrating a method for collecting stack traces according to an embodiment of the present invention.

[0013] [Figure 7] FIG. 2 is a block diagram illustrating a stack trace tree according to one embodiment of the present invention.

[0014] [Figure 8] FIG. 1 is a block diagram illustrating a computing device according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0015] Embodiments of the present invention relate to stack-based memory allocation, and more particularly to monitoring the amount of stack memory used by a program and optimizing the program accordingly. Stack memory, also referred to as a stack, is an area of ​​memory utilized by currently executing functions of a program so that the functions can store data. Data stored on the stack is stored in a last-in, first-out manner, and the stack grows from a base address in memory as the number of functions executing at a particular time, the amount of data stored by each function, or both, increases. The span of memory addresses from the base of the stack to the memory address where the most recently stored data is stored represents the program's current stack usage. If the maximum stack usage is known, a volume of memory equal to the maximum stack usage can be reserved, thereby ensuring that the program has enough memory to run without unnecessarily reserving more memory than necessary.

[0016] However, the maximum stack usage of a program may not be known in advance; rather, determining stack usage may require analyzing the program at runtime. Traditional approaches to determining a program's stack usage require running the program under a supervisor, linking additional cumbersome code into the program as part of compilation or post-processing, or checking the stack level at short time intervals. Because a program may contain thousands of functions, these approaches typically affect or disrupt program execution and can be very tedious. Thus, traditional techniques for measuring stack usage are not feasible in customer production environments.

[0017] In contrast, embodiments of the present invention can determine both a program's maximum stack usage and stack usage at a per-function level in a manner that does not require instrumentation or timer-based analysis. Embodiments of the present invention can determine stack usage without affecting program execution, thereby providing a practical approach that enables stack usage to be determined in production environments or other use cases. In particular, embodiments of the present invention can utilize existing function tracing systems implemented in most programming languages ​​to automatically capture stack usage data each time a program enters or exits a function, or both. Furthermore, embodiments of the present invention can exhaustively collect data corresponding to all use cases of a program, including data representing variables and program state, thereby improving the debugging process by allowing users to quickly find code that closely matches their stack trace.

[0018] Thus, embodiments of the present invention provide improved techniques for determining a program's stack usage. Knowing the maximum stack usage allows a program to be optimized to use only the amount of stack required for execution, avoiding the possibility of stack overflow errors or stack exhaustion bugs. Furthermore, embodiments of the present invention can collect data about a program's execution that is not normally available, including execution paths that take variables or program state into account, thereby providing a comprehensive overview of a program's execution and improving debugging. Thus, embodiments of the present invention have practical applications that improve the computing field by reducing the amount of computing resources consumed by programs, increasing program stability, and providing improved debugging techniques.

[0019] It should be noted that throughout this specification, references to features, advantages, or similar language do not imply that all of the features and advantages that may be realized in the embodiments disclosed herein should or will be present in any single embodiment of the invention. Rather, language referring to features and advantages is understood to mean that a particular feature, advantage, or characteristic described in the context of one embodiment is included in at least one embodiment of the invention. Thus, descriptions of features, advantages, and similar language throughout this specification may, but do not necessarily, refer to the same embodiment.

[0020] Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that the invention may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, certain embodiments may recognize additional features and advantages that may not be present in all embodiments of the invention.

[0021] These features and advantages will become more fully apparent from the following drawings, description, and appended claims, or may be learned by the practice of the embodiments of the invention as set forth hereinafter.

[0022] Embodiments of the present invention will now be described in detail with reference to the figures. Figure 1 is a block diagram illustrating a computing environment 100 for determining stack usage according to one embodiment of the present invention. As shown, computing environment 100 includes a client device 105, a debug server 140, and a network 160. It should be understood that the division of functionality among the components of computing environment 100 has been selected for purposes of illustrating embodiments of the present invention and should not be construed as a limiting example.

[0023] Client device 105 includes network interface (I / F) 106, at least one processor 107, memory 110, and database 135. Memory 110 may include compiler module 115, program 120, marker analysis module 125, and test module 130. Client device 105 may include a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, personal digital assistant (PDA), smartphone, thin client, or any programmable electronic device capable of executing computer-readable program instructions. Network interface 106 enables components of client device 105 to send and receive data over a network, such as network 160. Generally, client device 105 enables development of software applications, determination of stack usage by applications, and optimization of applications. Client device 105 may include internal and external hardware components, as shown and described in further detail with respect to FIG. 8.

[0024] Compiler module 115, program 120, marker analysis module 125, and test module 130 may include one or more modules or units for performing various functions of the embodiments of the present invention described below. Compiler module 115, program 120, marker analysis module 125, and test module 130 may be implemented by any combination of any amount of software and / or hardware modules or units and may reside in memory 110 of client device 105 for execution by a processor, such as processor 107.

[0025] Compiler module 115 may include any conventional or other computer program for translating computer code written in one programming language into another. Compiler module 115 may translate source code from a high-level programming language into a lower-level language (e.g., assembly language, object code, or machine code) to create an executable program. For example, compiler module 115 may compile source code written in the Java or C# programming languages ​​to generate an executable application.

[0026] Program module 120 may include a tracing system implemented by inserting tracing functions into functions of program 120 to capture stack traces during execution. Thus, as the program enters or exits each function, the tracing functions are called and a stack trace is captured. A stack trace is a report of the active stack frames at a particular point during program execution. Each stack frame can be considered a collection of all information on the stack for a particular function call, and may include local variables, saved copies of registers modified by the function that may need to be restored, argument parameters, and a return address (to allow a return statement to return to the correct location). Thus, because a stack trace represents a snapshot of the program at a particular point in its execution and indicates the currently active function, the stack trace may be useful for debugging or other purposes.

[0027] The trace function inserted by the tracing system can be used to call an intercept function during the runtime of any program compiled by compiler module 115. In particular, the runtime configuration of a program, such as program 120, may specify that the trace function call the intercept function, record the stack frame of the test case, or both. Furthermore, runtime parameters for the program may not be provided, in which case the tracing system may not affect the execution of the program. Thus, when a particular function is called, the trace function may be called, which in turn may call the intercept function.

[0028] The intercept function may insert a stack marker into the stack, which may contain a variable intended to mark a particular location in stack memory. The intercept function may obtain the memory address of the stack marker and may save that memory address and the corresponding name of the program's current function. Because the stack grows in a particular direction (either ascending or descending memory address order), the memory address of the stack marker can represent the program's stack usage at that time for a given function. Additionally, the intercept function may store a thread identifier or a process identifier, or both, corresponding to the executing function along with the memory address of the stack marker and the name of the function.

[0029] Program 120 may include any software application compiled by compiler module 115 according to embodiments of the present invention. As such, program 120 may include trace functions inserted into each of program 120's functions, which may themselves call the intercept function. Program 120 may perform any desired operations supported by the source code language. Program 120 is shown and described in further detail with respect to FIG. 2.

[0030] Marker analysis module 125 may analyze stack marker data obtained through an intercept function inserted in program 120. Marker analysis module 125 may analyze stack marker data received in real time during execution of program 120, or may analyze stack marker data provided after execution of program 120. In some embodiments, marker analysis module 125 determines peak or maximum stack usage by comparing the memory address of each stack marker with the data address corresponding to the base of the stack. Because the stack grows only in one specific direction, the stack marker whose memory address is furthest from the data address indicates the point where program 120 consumed the most stack. Because each memory address stores a known number of bits, determining the difference between the memory address of the stack marker and the data address correlates to the exact number of bits. The distance from a particular memory address to the data address in the stack is referred to as the stack depth, and the stack marker with the greatest stack depth during program execution corresponds to the peak or maximum stack usage of the program.

[0031] In some embodiments, the marker analysis module 125 determines per-function stack usage by comparing the memory addresses of stack markers for a first function and a second function called by the first function. In particular, when a function calls another function, the stack grows by an amount equal to or approximately equal to the stack memory usage of the called function. Thus, stack usage can be determined at a per-function level by determining the difference in memory addresses between adjacent stack markers in the stack (e.g., a stack marker and its nearest neighbor).

[0032] Test module 130 may include a regression test suite that can run both functional and non-functional tests on the program to test the program's performance. In some embodiments, test module 130 runs tests to ensure that the software still functions as expected after changes are made to the software. In particular, test module 130 may run tests to test changes to the program when internal bugs or customer issues are fixed or when new features are added to the program. Test module 130 may examine all code paths of a program, such as program 120, to ensure maximum code coverage is achieved and data is collected for all of the program's functions.

[0033] In some embodiments, when a program such as program 120 is tested by test module 130, function entry or exit, or both, invokes an intercept function, causing a stack trace to be captured at that point. In some embodiments, the stack trace and corresponding test case number (e.g., for the test case associated with that code path) are stored in a database, such as database 135. In some embodiments, the stack trace and test case number are stored in a test log generated by test module 130, and the resulting test log is processed to obtain and store the stack traces and corresponding test case numbers. Test module 130 may generate a test dataset for the program that includes stack traces, stack trace identifiers (i.e., a unique identifier for each unique stack trace), and a list of test case numbers for test cases that can reproduce each stack trace. The test dataset generated by test module 130 may be uploaded to a server, such as debug server 140, to enable other developers and users to perform debugging tasks, such as reproducing a problem.

[0034] In some embodiments, the test dataset is stored by generating a tree structure where each node represents a function, with the root node corresponding to the main function and child nodes corresponding to functions called by the main function. Thus, a node at level n represents a stack trace with a depth of n functions. At each node, a list of test cases that call the current function represented by that node may be stored. In some embodiments, the list may be a compressed list of test cases that encompass a particular function, and a bit vector or other suitable compressed storage method may be used to represent this list.

[0035] Database 135 may include any non-volatile storage medium known in the art. For example, database 135 may be implemented on a tape library, an optical library, one or more independent hard disk drives, or multiple hard disk drives in a redundant array of independent disks (RAID). Similarly, data in database 135 may conform to any suitable storage architecture known in the art, such as a file, a relational database, an object-oriented database, or one or more tables, or a combination thereof. In some embodiments, database 135 may store data including source code, compiled program data, program peak stack usage and stack usage per function data, test data sets, stack trace data, etc.

[0036] Debug server 140 includes network interface (I / F) 141, at least one processor 142, memory 145, and database 155. Memory 145 may include query processing module 150. Debug server 140 may include a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, personal digital assistant (PDA), smartphone, thin client, or any programmable electronic device capable of executing computer-readable program instructions. Network interface 141 enables components of debug server 140 to send and receive data over a network, such as network 160. Generally, debug server 140 stores test data sets for programs to enable developers and users to perform debugging tasks, such as reproducing problems. Debug server 140 may include internal and external hardware components, as shown and described in further detail with respect to FIG. 8 .

[0037] Query processing module 150 may include one or more modules or units for performing various functions of embodiments of the present invention described below. Query processing module 150 may be implemented by any amount or combination of software and / or hardware modules or units and may reside in memory 145 of debug server 140 for execution by a processor, such as processor 142.

[0038] Query processing module 150 may receive and process queries from remote computing devices, such as client device 105 or other computing devices, or a combination thereof. In particular, a query may include an error report obtained from a program, which an engineer can use to attempt to replicate the error in order to identify the root cause of the error and formulate a fix. As such, a query may include a stack trace corresponding to an error encountered by the program. Query processing module 150 can analyze the received stack traces to identify identical or similar stack traces stored in database 155, which may be populated with stack traces and other test data generated by test module 130 (e.g., stack trace identifiers (i.e., a unique identifier for each unique stack trace) and a list of test case numbers for test cases that can reproduce each stack trace). Query processing module 150 responds to the query by providing data including test case numbers, test cases that reproduced the identified stack traces, or a combination thereof, that may be useful for reproducing the error whose corresponding stack trace was included in the query.

[0039] Query processing module 150 may identify stack traces that are identical or similar to the stack trace provided in the query by comparing the stack frames of the queried stack trace with the stack frames of each stack trace in database 155 to find the closest match. In some embodiments, the closest match is determined based on the maximum number of stack frames that match between the queried stack trace and the stack traces in database 155. Thus, query processing module 150 may iteratively compare the stack frames of the queried stack trace with each of the stack traces in database 155 until the closest or exact match can be identified for a given program.

[0040] In some embodiments, query processing module 150 utilizes the tree structure generated by test module 130 to perform query processing. In particular, traditional or other maximal subtree identification techniques can be used to identify specific subtrees, and therefore associated test cases, that are closest matches to the query backtrace.

[0041] Database 155 may include any non-volatile storage medium known in the art. For example, database 155 may be implemented on a tape library, an optical library, one or more independent hard disk drives, or multiple hard disk drives in a redundant array of independent disks (RAID). Similarly, the data in database 155 may conform to any suitable storage architecture known in the art, such as a file, a relational database, an object-oriented database, or one or more tables, or a combination thereof. In some embodiments, database 155 may store data regarding a test dataset of a program, including stack trace data, stack trace identifiers (i.e., a unique identifier for each unique stack trace), a list of test case numbers for test cases that can reproduce each stack trace, stack trace trees, etc.

[0042] Network 160 may include a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, including wired, wireless, or fiber optic connections. In general, network 160 may be any combination of connections and protocols known in the art that support communication between client device 105, debug server 140, or other computing devices, or combinations thereof, via their respective network interfaces, according to embodiments of the present invention.

[0043] FIG. 2 is a block diagram illustrating program 120 at runtime according to one embodiment of the present invention. As shown, program 120 includes multiple functions 205A-205N and an intercept function 210 inserted into each function. Each function 205A-205N may call one or more other functions during execution of program 120 to achieve a particular programming goal. Intercept function 210 may be called each time any of functions 205A-205N is called. When intercept function 210 is called, it may store a stack marker on the stack, obtain the memory address of the stack marker, and store the memory address along with the name, thread identifier, and process identifier of the current function. Data stored by intercept function 210 on each call (e.g., the memory address, function name, thread identifier, or process identifier, or a combination thereof) may be stored in an off-stack location, such as non-volatile memory (e.g., database 135).

[0044] 3 is a block diagram illustrating a stack 300 according to one embodiment of the present invention. As shown, stack 300 grows upward, with each new function being called storing data on top of stack 300. Stack 300 contains multiple stack frames, including stack frames for one or more previous functions, a stack frame for a function named "FUNCTION_1," and a stack frame for a function named "FUNCTION_2." Each stack frame corresponds to the data that a given function stores on the stack.

[0045] Each stack frame may contain parameters, which are argument values ​​passed to the function. In the illustrated example, FUNCTION_1 stores parameter 310, and FUNCTION_2 stores parameter 340. On top of these parameters, the functions store a return address that points to the caller of the function. In the illustrated example, because FUNCTION_2's stack frame is above FUNCTION_1's stack frame, FUNCTION_1 is the calling function that called FUNCTION_2, and therefore return address 350 points to the address of FUNCTION_1. And return address 320 points to the calling function of FUNCTION_1.

[0046] A function's locals correspond to the storage space of its local variables, if any. The stack markers stored by the intercept function for each function are stored in locals. In the illustrated example, FUNCTION_2's stack marker is stored in local 360, and FUNCTION_1's stack marker is stored in local 330. Because a function's local variables are stored above the function's stack frame, the distance from one stack marker to another corresponds to the function's span and therefore stack usage. In particular, FUNCTION_2's stack usage can be obtained by determining the distance in memory from FUNCTION_2's stack marker to FUNCTION_1's stack marker.

[0047] FIG. 4 is a block diagram 400 illustrating the collection of stack usage data according to one embodiment of the present invention. As shown, a first function 405 named “function1” calls a second function 410 named “function2,” which in turn calls a third function 415 named “function3.” The example code for each function includes a traceEntry function corresponding to an intercept function, such that the intercept function is called by each of functions 405, 410, and 415. Also shown in the example code, the intercept function creates a variable (here, an integer named “marker”), obtains the memory address of the variable, and obtains the name of the current function. A table 420 of functions and the corresponding memory addresses of their stack markers can be assembled and analyzed to identify stack usage. In particular, stack usage at each entry of a function can be determined based on the memory address of the function’s stack marker. The stack usage at each function entry may be provided as a usage summary 425, which can be sorted to generate a table 430 showing the maximum stack usage achieved during program execution.

[0048] FIG. 5 is a flow chart illustrating a method 500 for determining stack usage according to one embodiment of the present invention.

[0049] At operation 510, the program is compiled and execution of the compiled program begins. The program may be compiled using a compiler that natively supports a stack tracing system. At runtime, the program's configuration may specify that the stack tracing system call an intercept function to enable monitoring of stack usage, or the configuration may specify that the stack tracing system record stack traces for test cases (as shown and described in further detail with respect to FIG. 6), or both. Thus, as the executing program enters or exits each function, a trace function may be called to optionally capture a stack trace, or the trace function may call the intercept function, or both.

[0050] In operation 520, as the program enters or exits each function, or both, a stack marker is stored, and the memory address of the stack marker is obtained along with each function's name, thread identifier, or process identifier, or a combination thereof. The memory address of each stack marker may be obtained as an operation subsequent to the creation of the stack marker because each particular stack marker may not reside in memory for very long because the function may exit and a pop operation may render the stack marker unretrievable. The intercept function may include code to write the memory address of the stack marker, along with the function's name and the function's thread identifier and process identifier, to a particular location, such as a location in non-volatile storage or another location off the stack.

[0051] The obtained information is analyzed to determine peak stack usage and stack usage per function in operation 530. For each function called by another function, the stack usage of the called function can be determined by comparing the stack marker memory address of the called function with the stack marker memory address of the calling function. Thus, by determining the difference in memory addresses, the stack usage of an individual function can be determined. Additionally, or alternatively, the memory address can be compared with the data memory address representing the bottom of the stack to determine the current stack usage at the time a given function is called, as well as the maximum stack usage of the program. In some embodiments, a vector stores the value of the current stack usage, and the vector overwrites the value with a new value in response to the intercept function obtaining a memory address farther from the data address than the currently stored value. Thus, the vector can always store the value associated with the highest stack usage encountered, and when the program finishes execution, the value stored in the vector should correspond to the maximum stack usage of the program.

[0052] In some embodiments, the obtained information may be processed to remove outliers or bad data. Additionally, or alternatively, the program may be run multiple times to identify and then remove outliers or bad data. Stack usage per function may be sorted and presented by usage, such that functions are ranked in a particular usage order, such as from most to least or from least to most. Maximum stack usage may be presented along with an indication of the function associated with the maximum stack usage, or the stack trace when the maximum stack usage occurred, or both. Stack sizes may be recommended per thread or per process based on stack usage data.

[0053] In operation 540, the program is optimized. In some embodiments, the program may be optimized by recompiling the program so that it does not allocate more memory on the stack than was utilized during the peak stack usage. In some embodiments, code refactoring operations may be performed to modify the order in which functions are called so that one or more of the functions active at the peak stack usage are instead called at another point during execution, thereby reducing the peak stack usage. These code optimizations may be performed in combination with each other and / or other conventional or novel optimization techniques, or may be performed automatically to produce an optimized program.

[0054] FIG. 6 is a flow chart illustrating a method 600 for collecting stack traces according to one embodiment of the present invention.

[0055] In operation 610, the program is tested using a regression suite. The regression suite may test the program by running several tests that exercise the program through all possible code paths and check the program's integrity, including both functional and non-functional tests.

[0056] At operation 620, a stack trace of the program is obtained. The stack trace may be obtained at the entry or exit or both of each function during the test and may include data corresponding to the current stack frame at each particular time. Additionally, the data may include variables or program state, or a combination thereof, at each time the trace function is called (i.e., at function entry / exit).

[0057] At operation 630, a request is received that includes a stack trace associated with an error. The stack trace may be generated by a program executing on the requesting entity's computing device or another computing device as a result of the program encountering an error.

[0058] The received stack trace is compared to other stack traces of the program to identify the closest match, in operation 640. A database may store stack traces of the program, including functions active at each branch of execution, and one or more test cases (i.e., the specific tests executed by the regression test suite) used to obtain each stack trace. In some embodiments, a stack trace tree is constructed with a root node corresponding to the calling function and child nodes corresponding to the called functions, and each node may contain one or more test cases associated with the node's function. Thus, a maximum common subtree search can be performed using the received stack trace to obtain one or more test cases associated with the lowest-level node.

[0059] In operation 650, the test case corresponding to the closest matching stack trace is returned to the requesting entity. The test case corresponds to the program state determined by the regression test suite to be closest to the state associated with the error encountered by the requesting entity. The test case can then be used to replicate the problem so that debugging can be performed.

[0060] 7 is a block diagram illustrating a stack trace tree 700 according to one embodiment of the present invention. As shown, stack trace tree 700 includes multiple nodes, each corresponding to a function in the program. As the program is tested multiple times using a regression test suite, a stack trace for each function can be obtained, and the stack trace can be associated with a test that passed or failed. Furthermore, because each node stores one or more test cases associated with a stack trace, the state corresponding to each stack trace can be replicated. In some embodiments, stack trace tree 700 can be used to quickly identify functions that specifically require additional testing.

[0061] When a request containing a stack trace is received, the request may be compared to each subtree of stack trace tree 700 to identify the closest match. For example, if a request contains stack traces of DoFailed, DoX, and RunX, subtree 705 is selected based on a maximal subtree identification technique, and the test case associated with the DoFailed node is provided to the requesting entity.

[0062] 8 is a block diagram illustrating components of a computer 10 suitable for implementing the methods disclosed herein. The computer 10 may implement a client device 105, a debug server 140, or both, according to embodiments of the present invention. It should be understood that FIG. 8 is merely provided as an illustration of one embodiment and does not suggest any limitations on the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

[0063] As shown, computer 10 includes a communications fabric 12 that provides communication between a computer processor 14, memory 16, persistent storage 18, communications units 20, and input / output (I / O) interfaces 22. Communications fabric 12 may be implemented with any architecture designed to convey data or control information, or both, between a processor (e.g., a microprocessor, communications and network processor, etc.), system memory, peripheral devices, and any other hardware components in the system. For example, communications fabric 12 may be implemented with one or more buses.

[0064] Memory 16 and persistent storage 18 are computer-readable storage media. In the illustrated embodiment, memory 16 includes random access memory (RAM) 24 and cache memory 26. In general, memory 16 may include any suitable volatile or non-volatile computer-readable storage media.

[0065] One or more programs may be stored in persistent storage 18 for execution by one or more of the respective computer processors 14 via one or more memories of memory 16. Persistent storage 18 may be a magnetic hard disk drive, a solid-state hard drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0066] The media used by persistent storage 18 may be removable. For example, a removable hard drive may be used for persistent storage 18. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive to transfer data to another computer-readable storage medium that is also part of persistent storage 18.

[0067] Communications unit 20, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 20 includes one or more network interface cards. Communications unit 20 may provide communications through the use of either or both physical and wireless communications links.

[0068] I / O interface 22 allows for the input and output of data by other devices that may be connected to computer 10. For example, I / O interface 22 may provide connection to external devices 28, such as a keyboard, keypad, touch screen, or any other suitable input device, or combination thereof. External devices 28 may also include portable computer-readable storage media, such as, for example, thumb drives, portable optical or magnetic disks, and memory cards.

[0069] Software and data used to implement embodiments of the present invention may be stored on such portable computer-readable storage media and loaded into persistent storage 18 via I / O interface 22. I / O interface 22 may be connected to a display 30. Display 30 provides a mechanism for displaying data to a user and may be, for example, a computer monitor.

[0070] The programs described herein are identified based on the applications for which they are implemented in particular embodiments of the invention. However, it should be understood that any specific program names herein are used merely for convenience, and that the invention should not be limited to use with any particular application identified or suggested, or both, by such names.

[0071] Data related to determining stack memory usage and optimizing programs (e.g., program data, memory address data, stack usage data, stack trace data, etc.) may be stored in any conventional or other data structure (e.g., file, array, list, stack, queue, record, etc.) or in any desired storage unit (e.g., database, data or other repository, queue, etc.). Data transmitted between client device 105 or debug server 140, or both, may include any desired format and organization and may include any quantity, type, and size of fields for storing data. The definition and data model of any data set may represent the overall structure in any desired manner (e.g., computer-related language, graphical representation, list, etc.).

[0072] Data related to determining stack memory usage to optimize programs (e.g., program data, memory address data, stack usage data, stack trace data, etc.) may include any information provided to or generated by client device 105, debug server 140, or both. Data related to determining stack memory usage to optimize programs may include any desired format and organization, and may include any quantity, type, and size of fields to store any desired data. Data related to determining stack memory usage to optimize programs may include any data collected about an entity by any collection mechanism, any combination of collected information, and any information derived from analysis of collected information.

[0073] Embodiments of the present invention may use any number and type of user interface (e.g., graphical user interface (GUI), command line, prompt, etc.) to obtain or provide information (e.g., data related to determining stack memory usage to optimize programs), where the interface may include any information organized in any manner. The interface may include any number and type of input or actuation mechanisms (e.g., buttons, icons, fields, boxes, links, etc.) located in any position for entering / displaying information and initiating desired actions via any suitable input device (e.g., mouse, keyboard, etc.). Interface screens may include any suitable actuators (e.g., links, tabs, etc.) for navigating between screens in any manner.

[0074] It will be understood that the embodiments described above and illustrated in the figures represent only a few of the many ways to monitor a program's stack memory usage.

[0075] The environment for embodiments of the present invention may include any number of computers or other processing systems (e.g., client or end-user systems, server systems, etc.) and databases or other repositories configured in any desired manner, where embodiments of the present invention may be applied to any desired type of computing environment (e.g., cloud computing, client-server, network computing, mainframe, standalone systems, etc.). The computers or other processing systems used by embodiments of the present invention may be implemented by any number of personal or other types of computers or processing systems (e.g., desktops, laptops, PDAs, mobile devices, etc.) and may include any commercially available operating system and any combination of commercially available and custom software (e.g., communications software, server software, compiler module 115, program 120, marker analysis module 125, test module 130, query processing module 150, etc.). These systems may include any type of monitor and input device (e.g., keyboard, mouse, voice recognition, etc.) for entering or viewing information, or both.

[0076] It should be understood that the software of embodiments of the present invention (e.g., communications software, server software, compiler module 115, program 120, marker analysis module 125, test module 130, query processing module 150, etc.) may be implemented in any desired computer language and could be developed by one of ordinary skill in the computer arts based on the functional descriptions contained herein and the flowcharts illustrated in the drawings. Furthermore, any references herein to software performing various functions generally refer to a computer system or processor that performs those functions under software control. The computer system of embodiments of the present invention may alternatively be implemented by any type of hardware or other processing circuitry or combination thereof.

[0077] Various functions of a computer or other processing system may be distributed in any manner among any number of software and / or hardware modules or units, processing systems, or computer systems and / or circuits, where the computers or processing systems may be located locally or remotely from one another and may communicate via any suitable communications medium (e.g., LAN, WAN, intranet, Internet, hardwire, modem connection, wireless, etc.). For example, functions of embodiments of the present invention may be distributed in any manner among various end-user / client and server systems, or any other intermediate processing device, or combination thereof. The software or algorithms or combinations thereof described above and illustrated in flowcharts may be modified in any manner to achieve the functions described herein. Furthermore, the functions in the flowcharts or herein may be executed in any order to achieve the desired operations.

[0078] The software of embodiments of the present invention (e.g., communications software, server software, compiler module 115, program 120, marker analysis module 125, test module 130, query processing module 150, etc.) may be available on a computer-usable, non-transitory medium (e.g., magnetic or optical media, magneto-optical media, floppy diskettes, CD-ROMs, DVDs, memory devices, etc.) of a stationary or portable program product apparatus or device for use in a stand-alone system or in a system connected by a network or other communications medium.

[0079] The communications network may be implemented by any number and type of communications network (e.g., LAN, WAN, Internet, intranet, VPN, etc.). The computer or other processing system of embodiments of the present invention may include any conventional or other communications device for communicating over the network via any conventional or other protocol. The computer or other processing system may utilize any type of connection (e.g., wired, wireless, etc.) to access the network. The local communications medium may be implemented by any suitable communications medium (e.g., local area network (LAN), hardwire, wireless link, intranet, etc.).

[0080] The system may store information (e.g., data related to determining stack usage to optimize programs) using any number of any conventional or other databases, data stores, or storage structures (e.g., files, databases, data structures, data, or other repositories, etc.). The database system may be implemented to store information (e.g., data related to determining stack usage to optimize programs) using any number of any conventional or other databases, data stores, or storage structures (e.g., files, databases, data structures, data, or other repositories, etc.). The database system may be included in or coupled to a server or client system, or both. The database system or storage structure, or combination thereof, may be remote from or local to a computer or other processing system and may store any desired data (e.g., data related to determining stack usage to optimize programs).

[0081] Embodiments of the present invention may use any number and type of user interface (e.g., graphical user interface (GUI), command line, prompt, etc.) to obtain or provide information (e.g., data related to determining stack usage to optimize programs), where the interface may include any information organized in any manner. The interface may include any number and type of input or actuation mechanisms (e.g., buttons, icons, fields, boxes, links, etc.) located in any position for entering / displaying information and initiating desired actions via any suitable input device (e.g., mouse, keyboard, etc.). Interface screens may include any suitable actuators (e.g., links, tabs, etc.) for navigating between screens in any manner.

[0082] Embodiments of the present invention are not limited to the particular tasks or algorithms described above, but may be utilized in any number of applications in related fields, including, but not limited to, analyzing stack usage of a running program and optimizing the program accordingly.

[0083] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Furthermore, it will be understood that the terms "comprises," "comprising," "includes," "including," "has," "have," "with," and the like, when used herein, specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0084] In the following claims, the corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements are intended to include any structure, material, or acts for performing the function as specifically claimed in combination with other claimed elements. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments were chosen and described to best explain the principles and practical application of the invention and to enable those skilled in the art to understand the invention in various embodiments, with various modifications suitable for the particular uses contemplated.

[0085] While the description of various embodiments of the present invention has been presented for illustrative purposes, it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art that do not depart from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0086] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. A computer program product may include a computer-readable storage medium or media having computer-readable program instructions that cause a processor to perform aspects of the present invention.

[0087] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0088] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0089] The computer-readable program instructions for performing the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the “C” programming language, or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions using state information of the computer readable program instructions to personalize the electronic circuitry in order to carry out aspects of the present invention.

[0090] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0091] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to create a machine, such that the instructions, executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or any combination thereof. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or any combination thereof, to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein constitutes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or any combination thereof.

[0092] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to execute a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks in the flowcharts or block diagrams, or a combination thereof.

[0093] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implements a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be realized as a single step, or may be executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of a block diagram or flowchart illustration, or combination thereof, and combinations of blocks in block diagrams or flowchart illustrations, or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or a combination of special-purpose hardware and computer instructions.

Claims

1. 1. A computer-implemented method for monitoring stack usage, comprising: executing an intercept function to store a stack marker on the stack, said intercept function being called as the program enters or exits each of a plurality of functions of said program; identifying a plurality of stack markers in the stack and determining a memory address of each stack marker during execution of the program to obtain a plurality of memory addresses; analyzing the plurality of memory addresses to identify a particular memory address associated with a maximum stack depth; determining the program's stack usage based on the maximum stack depth; 1. A computer-implemented method comprising:

2. comparing a first memory address of a stack marker for a particular function to a second memory address of a second stack marker associated with a caller function of the particular function to determine per-function stack usage for the particular function. The computer-implemented method of claim 1 further comprising:

3. determining the stack usage for each of the plurality of functions. The computer-implemented method of claim 2 further comprising:

4. The computer-implemented method of claim 1 , wherein the invocation of the intercept function causes the intercept function to obtain one or more of a function name, a thread identifier, and a process identifier.

5. generating an optimized program corresponding to the program, the optimized program having stack memory allocated based on the determination of stack usage of the program; The computer-implemented method of claim 1 , further comprising:

6. The computer-implemented method of claim 1 , wherein the invocation of the intercept function causes a stack trace of the program and a corresponding test case number to be obtained.

7. 7. The computer-implemented method of claim 6, wherein a plurality of stack traces and corresponding test case numbers for the program are obtained, and the plurality of stack traces and corresponding test case numbers are compared with a stack trace associated with an error to identify a test case corresponding to the error.

8. 1. A computer system for monitoring stack usage, comprising: one or more computer processors; one or more computer-readable storage media; program instructions stored on the one or more computer-readable storage media that are executed by at least one of the one or more computer processors; Equipped with The program instructions include: executing an intercept function causing a stack marker to be stored on the stack, said intercept function being called as the program enters or exits each of a plurality of functions of said program; identifying a plurality of stack markers in the stack and determining a memory address of each stack marker during execution of the program to obtain the plurality of memory addresses; analyzing the plurality of memory addresses to identify a particular memory address associated with a maximum stack depth; The stack usage of the program is determined based on the maximum stack depth. A computer system having instructions.

9. The program instructions include: Comparing a first memory address of a stack marker for a particular function to a second memory address of a second stack marker associated with a caller function of the particular function to determine per-function stack usage for the particular function. The computer system of claim 8 further comprising instructions.

10. The program instructions include: determining a stack usage for each of the plurality of functions; The computer system of claim 9 further comprising instructions.

11. The computer system of claim 8 , wherein the invocation of the intercept function causes the intercept function to obtain one or more of a function name, a thread identifier, and a process identifier.

12. The program instructions include: generating an optimized program corresponding to the program, the optimized program having stack memory allocated based on the determination of stack usage of the program; 11. A computer system according to any one of claims 8 to 10, further comprising instructions.

13. 11. The computer system of claim 8, wherein the invocation of the intercept function causes a stack trace of the program and a corresponding test case number to be obtained.

14. 14. The computer system of claim 13, wherein a plurality of stack traces and corresponding test case numbers for the program are obtained, and the plurality of stack traces and corresponding test case numbers are compared with a stack trace associated with an error to identify a test case corresponding to the error.

15. 1. A computer program for determining stack usage, comprising: On the computer, a step of executing an intercept function and storing a stack marker on a stack, the intercept function being called as the program enters or exits each of a plurality of functions of the program; identifying a plurality of stack markers in the stack and determining a memory address of each stack marker during execution of the program to obtain a plurality of memory addresses; analyzing the plurality of memory addresses to identify a particular memory address associated with a maximum stack depth; determining the program's stack usage based on the maximum stack depth; A computer program for executing

16. The computer, and further performing the step of comparing a first memory address of a stack marker for a particular function with a second memory address of a second stack marker associated with a caller function of the particular function to determine per-function stack usage for the particular function.

16. A computer program according to claim 15.

17. The computer, a step of determining a stack usage amount for each of the plurality of functions; 17. A computer program according to claim 16.

18. 18. The computer program product of claim 15, wherein the invocation of the intercept function causes the intercept function to obtain one or more of a function name, a thread identifier, and a process identifier.

19. The computer, generating an optimized program corresponding to the program, the optimized program having stack memory allocated based on the determination of stack usage of the program; 18. A computer program according to any one of claims 15 to 17.

20. 18. The computer program product of claim 15, wherein the invocation of the intercept function causes a stack trace of the program and a corresponding test case number to be obtained.

Images