Monitoring stack memory usage to optimize programs

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.

BACKGROUND

1. Technical Field

Present invention embodiments relate to stack-based memory allocation, and more specifically, to monitoring the amount of stack memory used by programs and optimizing programs accordingly.

2. Discussion of the Related Art

Stack is a specific memory region of a program in which 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. Stack is often used to store variables of fixed length local to the currently active functions. 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 conventions in use.

The amount of stack that a program requires may not be known a priori, but can be empirically determined using various techniques. In general, programmers seek to allocate an amount of stack that is sufficient for a program's requirements without allocating an excessive amount of stack, thus ensuring that the program can execute properly while avoiding the unnecessary consumption of computing resources.

SUMMARY

According to one embodiment of the present invention, 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.

DETAILED DESCRIPTION

Present invention embodiments relate to stack-based memory allocation, and more specifically, to monitoring the amount of stack memory used by programs and optimizing programs accordingly. Stack memory, also referred to as stack, is a region of memory that is utilized by currently-executing functions of a program so that the functions can store data. Data stored in a stack is stored in a last-in-first-out manner, and a stack grows from an origin address in memory as the number of functions executing at a particular time and/or the amount of data stored by each function increases. The span of memory addresses from the stack's origin to the memory address at which the most recently-stored data has been stored represents the current stack usage of a program. If the maximum stack usage is known, then a volume of memory equal to the maximum stack usage can be reserved, thus ensuring that a program has sufficient memory for execution without unnecessarily reserving more memory than is necessary.

However, the maximum stack usage of a program may not be known a priori; rather, determining stack usage may require analysis of the program at runtime. Conventional approaches to determining a program's stack usage require running the program under a monitoring program, linking additional, cumbersome code into the program as part of compilation or post-processing, or checking stack levels at short time intervals. These approaches typically impact or disrupt program performance, and can be very tedious, as a program may include thousands of functions. Thus, the conventional techniques to measure stack usage are not feasible in customer production environments.

In contrast, present invention embodiments can determine both the maximum stack usage of a program and stack usage on a per-function level in a manner that does not require instrumentation or timer-based analysis. Present invention embodiments can determine stack usage without impacting program performance, thereby providing a practical approach that enables stack usage to be determined in production environments or in other use-cases. In particular, present invention embodiments make use of a preexisting function tracing system that is implemented in most programming languages, enabling stack usage data to be automatically captured whenever a program enters and/or exits a function. Furthermore, present invention embodiments can exhaustively collect data corresponding to all use-cases of a program, including variables and data representative of a program's state, thereby improving the debugging process by enabling users to quickly find code that closely matches their own stack traces.

Accordingly, present invention embodiments offer improved techniques for determining stack usage of a program. Once the maximum stack usage is known, a program can be optimized such that the program uses only an amount of stack that is necessary for execution, while also avoiding potential stack overflow errors or stack exhaustion bugs. Additionally, present invention embodiments can collect data relating to a program's execution that is normally not obtainable, including execution paths that account for variables or program state, which improves debugging as an exhaustive overview of a program's execution can be obtained. Thus, present invention embodiments provide the practical application of improving the field of computing by reducing the amount of computing resources consumed by programs, by increasing the stability of programs, and by providing improved techniques for debugging.

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

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 embodiments of the invention as set forth hereinafter.

Present invention embodiments will now be described in detail with reference to the Figures.FIG.1is a block diagram depicting a computing environment100for determining stack usage in accordance with an embodiment of the present invention. As depicted, computing environment100includes a client device105, a debugging server140, and a network160. It is to be understood that the functional division among components of computing environment100have been chosen for purposes of explaining present invention embodiments and is not to be construed as a limiting example.

Client device105includes a network interface (I/F)106, at least one processor107, memory110, and a database135. Memory110may include a compiler module115, a program120, a marker analysis module125, and a testing module130. Client device105may include a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, a thin client, or any programmable electronic device capable of executing computer readable program instructions. Network interface106enables components of client device105to send and receive data over a network, such as network160. In general, client device105enables the development of software applications, determining of stack usage by applications, and optimization of applications. Client device105may include internal and external hardware components, as depicted and described in further detail with respect toFIG.8.

Compiler module115, program120, marker analysis module125, and testing module130may include one or more modules or units to perform various functions of present invention embodiments described below. Compiler module115, program120, marker analysis module125, and testing module130may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within memory110of client device105for execution by a processor, such as processor107.

Compiler module115may include any conventional or other computer program for translating computer code written in one programming language into another language. Compiler module115may translate source code from a high-level programming language to a lower level language (e.g., an assembly language, object code, or machine code) to create an executable program. For example, compiler module115may compile source code written in a Java or C#programming language to generate executable applications.

Program module120may include a tracing system that is achieved by inserting a tracing function into functions of program120to obtain stack traces during execution. Thus, when the program enters or exits each function, the tracing function is invoked, and a stack trace is obtained. A stack trace is a report of the active stack frames at a certain point in time during execution of a program. Each stack frame is considered to be a collection of all information on the stack pertaining to a particular function call, and can include local variables, saved copies of registers modified by functions that could need restoration, argument parameters, and a return address (which allows return statements to return to a correct location). Thus, a stack trace represents a snapshot of a program at a particular point of execution, and since a stack trace indicates the currently-active functions, stack traces may be useful for debugging or other purposes.

The tracing function inserted by the tracing system can be used to call an intercept function during runtime of any program compiled by compiler module115. In particular, runtime settings for a program, such as program120, may specify that the tracing function call an intercept function and/or record stack frames for test cases. Additionally, no runtime parameters for a program may be provided, in which case the tracing system may do nothing to affect a program's execution. Thus, when a particular function is called, the tracing function is invoked, which in turn may invoke the intercept function.

The intercept function may insert a stack marker into the stack, which can include a variable whose purpose is 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 a corresponding name of the program's current function. Since a stack grows in a particular direction (either in a direction of ascending or descending memory addresses), the memory address of the stack marker can, for a given function, represent the program's stack usage at that time. In addition, the intercept function may store, along with a memory address of a stack marker and the name of a function, the thread identifier and/or process identifier corresponding to the executing function.

Program120may include any software application compiled by compiler module115in accordance with present invention embodiments. As such, program120may include a tracing function that is inserted into each of the functions of program120, and the tracing function may itself call an intercept function. Program120may perform any desired operations that are supported by the source code language. Program120is depicted and described in further detail with respect toFIG.2.

Marker analysis module125may analyze the stack marker data obtained via the intercept function inserted into program120. Marker analysis module125may analyze stack marker data received in real-time during execution of program120, or may analyze stack marker data that is provided after execution of program120. In some embodiments, marker analysis module125determines the peak or maximum stack usage by comparing each stack marker's memory address to a datum address, which corresponds to the origin of a stack. As stacks grow only in one particular direction, the stack marker whose memory address is farthest from the datum address indicates the point at which program120consumed the most stack. As each memory address stores a known number of bits, determining the difference between a stack marker's memory address and a datum address correlates to an exact number of bits. The distance from a particular memory address in the stack to the datum address is referred to as the stack depth, and the stack marker that has the greatest stack depth during execution of a program corresponds to the peak or maximum stack usage of the program.

In some embodiments, marker analysis module125determines the per-function stack usage by comparing the memory addresses of the stack markers of a first function and a second function called by the first function. In particular, when a function calls another function, the stack is increased by an amount equal, or approximately equal, to the stack memory usage of the called function. Thus, by determining the difference in memory addresses between stack markers that are adjacent in the stack (e.g., a stack marker and its closet neighboring stack marker), stack usage can be determined on a per-function level.

Testing module130may include a regression test suite that can perform both functional and non-functional tests on a program to test the program's performance. In some embodiments, testing module130performs tests to ensure that software still performs as expected after a change in the software. In particular, testing module130may perform tests when an internal bug or customer issue is fixed, or when a new feature is added to a program, to test the changes to the program. Testing module130may run through all code paths of a program, such as program120, to ensure that maximum code coverage is achieved and data is collected for all of the functions of the program.

In some embodiments, when a program, such as program120, is tested by testing module130, entry and/or exit into a function invokes the intercept function and causes a stack trace to be obtained at that moment in time. In some embodiments, the stack trace and a corresponding test case number (e.g., for the test case associated with that code path) is stored in a database, such as database135. In some embodiments, the stack trace and test case number are stored to a test log generated by testing module130, and the resulting test log is processed to obtain and store stack traces and corresponding test case numbers. Testing module130may generate a test data set for a program that includes stack traces, stack trace identifiers (i.e. unique identifiers for each unique stack trace), and a list of test case numbers for test cases that can reproduce each stack trace. The test data sets generated by testing module130may be uploaded to a server, such as debugging server140, so that other developers and users can perform debugging tasks such as issue reproduction.

In some embodiments, a test data set is stored by generating a tree structure wherein each node represents a function: a root node corresponds to a main function, and child nodes correspond to functions that are called by the main function. thus, level n nodes represent stack traces having a depth of n functions. At each node, a list of test cases that invoke the current function represented by the node may be stored. In some embodiments, the list can be a compressed list of test cases that cover the particular function, and a bit vector or other suitable compressed storage method can be used to represent the list.

Database135may include any non-volatile storage media known in the art. For example, database135can be implemented with a tape library, 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 database135may conform to any suitable storage architecture known in the art, such as a file, a relational database, an object-oriented database, and/or one or more tables. In some embodiments, database135may store data including source code, compiled program data, program peak stack usage and per-function stack usage data, test data sets, stack trace data, and the like.

Debugging server140includes a network interface (I/F)141, at least one processor142, memory145, and a database155. Memory145may include a query processing module150. Debugging server140may include a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, a thin client, or any programmable electronic device capable of executing computer readable program instructions. Network interface141enables components of debugging server140to send and receive data over a network, such as network160. In general, debugging server140stores test data sets for programs so that developers and users can perform debugging tasks such as issue reproduction. Debugging server140may include internal and external hardware components, as depicted and described in further detail with respect toFIG.8.

Query processing module150may include one or more modules or units to perform various functions of present invention embodiments described below. Query processing module150may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within memory145of debugging server140for execution by a processor, such as processor142.

Query processing module150may receive and process queries from remote computing devices, such as client device105and/or other computing devices. In particular, the query may include an error report obtained from a program that can be used by technicians to attempt to duplicate an error in order to identify a root cause and formulate a fix for the error. As such, the query may include a stack trace corresponding to an error encountered by a program. Query processing module150may analyze the received stack trace to identify same or similar stack traces stored in database155, which may be populated with stack traces and other test data produced by testing module130(e.g., stack trace identifiers (i.e., unique identifiers for each unique stack trace), and a list of test case numbers for test cases that can reproduce each stack trace). Query processing module150responds to a query by providing data that includes the test case numbers and/or test cases that reproduced the identified stack trace, which can be useful in reproducing the error whose corresponding stack trace was included in the query.

Query processing module150may identify stack traces that are the same or similar to a stack trace provided in a query by comparing the stack frames of the queried stack trace to the stack frames of each stack trace in database155to find a 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 a stack trace in database155. Thus, query processing module150may iteratively compare stack frames of the queried stack trace to each of the stack traces in database155for a given program until a closest or exact match can be identified.

In some embodiments, query processing module150utilizes the tree structures generated by testing module130in order to perform query processing. In particular, conventional or other largest subtree identification techniques can be employed to identify a particular subtree, and therefore associated test cases, that is a closest match to a query's back trace.

Database155may include any non-volatile storage media known in the art. For example, database155can be implemented with a tape library, 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 database155may conform to any suitable storage architecture known in the art, such as a file, a relational database, an object-oriented database, and/or one or more tables. In some embodiments, database155may store data relating to test data sets for programs, including stack trace data, stack trace identifiers (i.e. unique identifiers for each unique stack trace), a list of test case numbers for test cases that can reproduce each stack trace, stack trace trees, and the like.

Network160may include a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and includes wired, wireless, or fiber optic connections. In general, network160can be any combination of connections and protocols known in the art that will support communications between client device105, debugging server140, and/or other computing devices via their respective network interfaces in accordance with embodiments of the present invention.

FIG.2is a block diagram depicting a program120at runtime in accordance with an embodiment of the present invention. As depicted, program120includes a plurality of functions205A-205N and an intercept function210inserted into each function. Each function205A-205N may call one or more other functions in order to achieve a particular programming goal during execution of program120. Intercept function210may be invoked whenever any of functions205A-205N are called. When intercept function210is invoked, intercept function210may store a stack marker in stack, obtain the memory address of the stack marker, and store the memory address along with the name of the current function, the thread identifier, and the process identifier. The data stored by intercept function210at each invocation (e.g., the memory address, function name, thread identifier, and/or process identifier) may be stored at a location outside of stack, such as non-volatile memory (e.g., database135).

FIG.3is a block diagram depicting a stack300in accordance with an embodiment of the present invention. As depicted, stack300grows upwardly, and as each new function is called, it stores data at the top of stack300. Stack300includes a plurality of stack frames, including stack frames for one or more preceding functions, a stack frame for a function named “FUNCTION_1,” and a stack frame for function named “FUNCTION_2.” Each stack frame corresponds to the data that a given function stores in the stack.

Each stack frame may include parameters, which are argument values that are passed on to the function. In the depicted example, FUNCTION_1 stores parameters310and FUNCTION_2 stores parameters340. On top of the parameters, a function stores the return address that points back to the function's caller. In the depicted example, since the stack frame for FUNCTION_2 is above the stack frame for FUNCTION_1, then FUNCTION_1 is the caller function that invoked FUNCTION2, and so, return address350points back to the address for FUNCTION_1. In turn, return address320points back to the caller function of FUNCTION_1.

The locals for a function corresponds to the storage space for local variables, if any. The stack marker stored by the intercept function for each function is stored in the locals. In the depicted example, the stack marker of FUNCTION_2 is stored in locals360, and the stack marker of FUNCTION_1 is stored in locals330. Since the local variables of a function are stored at the top of the function's stack frame, the distance from one stack marker to another corresponds to the span, and therefore stack usage, of the function. In particular, the stack usage of FUNCTION_2 can be obtained by determining the distance in memory from the stack marker for FUNCTION_2 to the stack marker for FUNCTION_1.

FIG.4is a block diagram400depicting the collection of stack usage data in accordance with an embodiment of the present invention. As depicted, a first function405named “function1” calls a second function410, named “function2,” which in turn calls a third function415named “function3.” The example code for each function includes a traceEntry function that corresponds to the intercept function; thus, the intercept function is invoked by each of functions405,410, and415. As is 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 table420of functions and the corresponding memory addresses of their stack markers can be assembled, which can be analyzed to identify stack usage. In particular, the 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 entry of each function can be provided as a usage summary425, which can be sorted to produce a table430that indicates a maximum stack usage achieved during execution of the program.

FIG.5is a flow chart depicting a method500of determining stack usage in accordance with an embodiment of the present invention.

A program is compiled and execution of the compiled program is initiated at operation510. The program may be compiled using a compiler that natively supports a stack tracing system. At runtime, a program's settings may specify that the stack tracing system calls an intercept function to enable monitoring of stack usage and/or the settings may specify that the stack tracing system records stack traces for test cases (as depicted and described in further detail with respect toFIG.6). Thus, as the executing program enters and/or exits each function, a tracing function can be invoked to optionally obtain a stack trace, and/or the tracing function may invoke the intercept function.

At operation520, stack markers are stored as the program enters and/or exits each function, and memory addresses of the stack markers are obtained along with the name of each function, a thread identifier, and/or a process identifier. The memory address for each stack marker may be obtained as a subsequent operation to creating the stack marker, as each particular stack marker may not reside in memory for very long since the function may exit and a pop operation may cause the stack marker to no longer be retrievable. The intercept function may include code to write the stack marker's memory address, along with the name of the function and thread identifier and process identifier for the function to a particular location, such as a non-volatile storage location or other location outside of the stack.

The obtained information is analyzed to determine the peak stack usage and a per-function stack usage at operation530. For each function called by another function, the stack usage of the called function can be determined by comparing the called function's stack marker memory address to the stack marker memory address of the caller function. Thus, by determining the difference in memory addresses, the stack usage of individual functions can be determined. Additionally or alternatively, the memory addresses can be compared to a datum memory address representing the bottom of the stack to determine a current stack usage at the time that a given function is invoked, as well as the maximum stack usage of the program. In some embodiments, a vector stores a value of a current stack usage, and in response to the intercept function obtaining a memory address that is farther from the datum address than the currently-stored value, the vector writes over the value with the new value. Thus, the vector may always store a value associated with a highest-yet-encountered stack usage, and when the program finishes execution, the value stored by the vector should correspond to the maximum stack usage of the program.

In some embodiments, the obtained information may be processed to remove outliers or bad data. Additionally or alternatively, a program may be executed a number of times in order to identify outliers or bad data, which is then removed. The per-function stack usage may be sorted by usage and presented such that the functions are ranked in a particular order of usage, such as greatest to least or least to greatest. The maximum stack usage may also be presented with an indication of the function associated with the maximum stack usage and/or a stack trace at the time that the maximum stack usage occurred. Stack sizes can be recommended per-thread or per-process based on the stack usage data.

The program is optimized at operation540. In some embodiments, the program may be optimized by recompiling the program such that the program does not allocate any more memory to the stack than the amount utilized during maximum 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 peak stack usage are instead called at another point in 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, and may be performed automatically to generate an optimized program.

FIG.6is a flow chart depicting a method600of collecting stack traces in accordance with an embodiment of the present invention.

A program is tested using a regression suite at operation610. The regression suite may test a program by performing a number of tests that cause the program to execute every possible code path, including both functional and non-functional tests to check the program's integrity.

Stack traces for the program are obtained at operation620. The stack traces may be obtained at entry and/or exit of each function during the testing, and may include data corresponding to the current stack frames at each particular time. Additionally, the data may include variables and/or program state at each time the tracing function is invoked (i.e. function entry/exit).

A request is received that includes a stack trace associated with an error at operation630. 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.

The received stack trace is compared to other stack traces for the program to identify a closest match at operation640. A database may store stack traces for a program that include the functions active at each branch of execution as well as one or more test cases (i.e., the particular tests performed by a regression test suite) used to obtain each stack trace. In some embodiments, a stack trace tree is constructed with root nodes corresponding to caller functions and child nodes corresponding to called functions; each node can include one or more test cases associated with the function of that node. Thus, the received stack trace can be used to perform a largest common subtree search, and the one or more test cases associated with the node at the bottommost level can be obtained.

Test cases corresponding to the closest-matching stack trace are provided back to the requesting entity at operation650. The test cases correspond to the program's state, as determined by the regression test suite, that is closest to the state associated with the error encountered by the requesting entity. Thus, the test cases can be used to replicate the problem so that debugging can be performed.

FIG.7is a block diagram depicting a stack trace tree700in accordance with an embodiment of the present invention. As depicted, stack trace tree700includes a plurality of nodes, each corresponding to one function of a program. As the program is tested a number of times using a regression testing suite, stack traces for each function can be obtained; the stack traces may be associated with passed or failed tests. Additionally, each node stores one or more test cases associated with the stack traces, so that the states corresponding to each stack trace can be replicated. In some embodiments, the stack trace tree700can be used to quickly identify functions in particular that require additional testing.

When a request including a stack trace is received, the request can be compared to each subtree of stack trace tree700in order to identify a closest match. For example, if the request includes a stack trace of DoFailed, DoX, and RunX, then subtree705will be selected based on a largest subtree identification technique, and the test cases associated with the DoFailed node will be provided to the requesting entity.

FIG.8is a block diagram depicting components of a computer10suitable for executing the methods disclosed herein. Computer10may implement client device105and/or debugging server140in accordance with embodiments of the present invention. It should be appreciated thatFIG.8provides only an illustration of one embodiment and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

As depicted, the computer10includes communications fabric12, which provides communications between computer processor(s)14, memory16, persistent storage18, communications unit20, and input/output (I/O) interface(s)22. Communications fabric12can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric12can be implemented with one or more buses.

Memory16and persistent storage18are computer readable storage media. In the depicted embodiment, memory16includes random access memory (RAM)24and cache memory26. In general, memory16can include any suitable volatile or non-volatile computer readable storage media.

One or more programs may be stored in persistent storage18for execution by one or more of the respective computer processors14via one or more memories of memory16. The persistent storage18may be a magnetic hard disk drive, a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

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

Communications unit20, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit20includes one or more network interface cards. Communications unit20may provide communications through the use of either or both physical and wireless communications links.

I/O interface(s)22allows for input and output of data with other devices that may be connected to computer10. For example, I/O interface22may provide a connection to external devices28such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices28can also include portable computer readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards.

Software and data used to practice embodiments of the present invention can be stored on such portable computer readable storage media and can be loaded onto persistent storage18via I/O interface(s)22. I/O interface(s)22may also connect to a display30. Display30provides a mechanism to display data to a user and may be, for example, a computer monitor.

Data relating to determining stack memory usage to optimize programs (e.g., program data, memory address data, stack usage data, stack trace data, etc.) may be stored within any conventional or other data structures (e.g., files, arrays, lists, stacks, queues, records, etc.) and may be stored in any desired storage unit (e.g., database, data or other repositories, queue, etc.). The data transmitted between client device105and/or debugging server140may include any desired format and arrangement, and may include any quantity of any types of fields of any size to store the data. The definition and data model for any datasets may indicate the overall structure in any desired fashion (e.g., computer-related languages, graphical representation, listing, etc.).

Data relating 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 device105and/or debugging server140. Data relating to determining stack memory usage to optimize programs may include any desired format and arrangement, and may include any quantity of any types of fields of any size to store any desired data. The data relating to determining stack memory usage to optimize programs may include any data collected about entities by any collection mechanism, any combination of collected information, and any information derived from analyzing collected information.

It will be appreciated that the embodiments described above and illustrated in the drawings represent only a few of the many ways of monitoring stack memory usage of programs.

It is to be understood that the software (e.g., communications software, server software, compiler module115, program120, marker analysis module125, testing module130, query processing module150, etc.) of the present invention embodiments 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 in the specification and flowcharts illustrated in the drawings. Further, any references herein of software performing various functions generally refer to computer systems or processors performing those functions under software control. The computer systems of the present invention embodiments may alternatively be implemented by any type of hardware and/or other processing circuitry.

The software of the present invention embodiments (e.g., communications software, server software, compiler module115, program120, marker analysis module125, testing module130, query processing module150, etc.) may be available on a non-transitory computer useable medium (e.g., magnetic or optical mediums, magneto-optic mediums, floppy diskettes, CD-ROM, DVD, memory devices, etc.) of a stationary or portable program product apparatus or device for use with stand-alone systems or systems connected by a network or other communications medium.

The present invention embodiments are not limited to the specific tasks or algorithms described above, but may be utilized for any number of applications in the relevant fields, including, but not limited to, analyzing stack usage of programs during execution and optimizing programs accordingly.