Memory leak detection

In accordance with aspects of the disclosure, systems and methods are provided for monitoring one or more classes for detecting suspected memory leaks in a production environment. The systems and methods may include identifying which of the one or more classes hold at least one static or non-static field of collection or array type, accessing the one or more classes that hold the at least one static or non-static fields of collection or array type, and tracking a size for each field of each class by periodically sampling the size of each field over an interval, processing the size data for each field of each class, and detecting suspected memory leaks of each class by identifying which of the one or more fields of each class exhibits suspect behavior in the size over the interval.

TECHNICAL FIELD

The present description relates to computer-based techniques for memory leak detection.

BACKGROUND

In computer related processes, a memory leak may arise when a software application or program holds memory for some use yet does not release the held memory back to the operating system. In some instances, a memory leak may manifest when an object is stored in memory and cannot be accessed by the process of the software application or program. In other instances, the opposite may occur where a reference to an object that is no longer needed may be held by a software application or program, which may inhibit the object from being garbage collected and thus create a memory leak. Further, memory leaks may be destructive due to their ability to exhaust available memory resources during execution of applications or programs, and memory leaks may negatively impact system performance. For instance, a memory leak may diminish performance by reducing availability of memory, and in some instances, a large portion of available memory may be allocated thereby causing parts of a system to cease working properly, causing an application or program to crash, and/or causing a system to become restrained and unexpectedly perform sluggishly. Generally, with conventional techniques, a memory leak may only be diagnosed by a programmer or operator with access to the source code of the application or program. Therefore, there currently exists a need to improve memory leak detection techniques and reduce the affects of memory leaks or leakage on system performance.

SUMMARY

In accordance with aspects of the disclosure, a computer system may be provided for memory leak detection including instructions stored on a non-transitory computer-readable medium and executable by at least one processor. The system may include a collection sizes tracker configured to cause the at least one processor to monitor one or more containing classes for detecting suspected memory leaks in a production environment. The collection sizes tracker may include an instrumentation manager configured to identify which of the one or more containing classes hold at least one static or non-static field of collection or array type. The collection sizes tracker may include a polling mechanism configured to access the one or more containing classes that hold the at least one static or non-static fields of collection or array type, and track a size for each field of each containing class by periodically sampling size data of each field over an interval, the one or more fields of each containing class enabling instances of each containing class to maintain at least one of state and behavior. The collection sizes tracker may include an algorithm handler configured to process the size data for each field of each containing class from the polling mechanism and detect suspected memory leaks of each containing class by identifying which of the one or more fields of each containing class exhibits suspect behavior in the size over the interval.

In accordance with aspects of the disclosure, a computer-implemented method may be provided for memory leak detection. In an implementation, the method may include monitoring one or more classes (containing classes) in a production environment and identifying which of the one or more classes (containing classes) hold at least one static or non-static field of collection or array type. The method may include accessing the one or more classes (containing classes) that hold the at least one static or non-static fields of collection or array type and tracking a size for each field of each class (containing class) by periodically sampling size data of each field over an interval, the one or more fields of each class (containing class) enabling instances of each class (containing class) to maintain at least one of state and behavior. The method may include processing the size data for each field of each class (containing class) and detecting suspected memory leaks of each class (containing class) by identifying which of the one or more fields of each class (containing class) exhibits suspect behavior in the size over the interval.

In accordance with aspects of the disclosure, a computer program product may be provided, wherein the computer program product is tangibly embodied on a computer-readable storage medium and includes instructions that, when executed by at least one processor, may be configured to monitor one or more containing classes in a production environment and identify which of the one or more containing classes hold at least one static or non-static field of collection or array type. The instructions, when executed by the at least one processor, may be further configured to access the one or more containing classes that hold the at least one static or non-static fields of collection or array type and track a size for each field of each containing class by periodically sampling size data of each field over an interval, the one or more fields of each containing class enabling instances of each containing class to maintain at least one of state and behavior. The instructions, when executed by the at least one processor, may be further configured to process the size data for each field of each containing class and detect suspected memory leaks of each containing class by identifying which of the one or more fields of each containing class exhibits suspect behavior in the size over the interval.

DETAILED DESCRIPTION

In various implementations, aspects of the disclosure provide a system and methods for detecting memory leaks that may result from growth of collections and/or arrays by tracking their field sizes through classes (containing classes). In this manner, classes identified to contain collections and/or arrays may be tracked, and the sizes of the collections and/or arrays may be checked periodically and tracked without great impact on performance. These periodical size samplings may be utilized as input to an algorithm to determine possible or potential memory leaks. Further, an output of this process may include potential memory leaks information regarding not only the collection and/or array that is suspect, but regarding classes (containing classes) and/or instances thereof.

FIG. 1is a block diagram illustrating an example system100for memory leak detection, in accordance with aspects of the disclosure.

In the example ofFIG. 1, the system100comprises a computer system for implementing a memory leak detection system that may be associated with a computing device104, thereby transforming the computing device104into a special purpose machine designed to determine and implement memory leak detection process(es), as described herein. In this sense, it may be appreciated that the computing device104may include any standard element(s) and/or component(s), including at least one processor(s)110, memory (e.g., non-transitory computer-readable storage medium)112, one or more optional database(s)140, power, peripherals, and various other computing elements and/or components that may not be specifically shown inFIG. 1. Further, the system100may be associated with a display device150(e.g., a monitor or other display) that may be used to provide a user interface (UI)152, such as a graphical user interface (GUI). In an implementation, the UI152may be used to receive preferences from a user for managing or utilizing the system100. As such, it should be appreciated that various other elements and/or components of the system100that may be useful to implement the system100may be added or included, as would be apparent to one of ordinary skill in the art.

Accordingly, in the example ofFIG. 1, the memory leak detection system100may include the computing device104and instructions recorded on the memory112(non-transitory computer-readable medium) and executable by the at least one processor110. Further, the memory leak detection system100may include the display device150for providing output to a user, and the display device150may include the user interface (UI)152for receiving input from the user.

As shown in the example ofFIG. 1, the memory leak detection system100may include a collection sizes tracker120configured to cause the at least one processor110to monitor one or more classes (containing classes) for detecting suspected memory leaks in a production environment. In various examples, a memory leak or memory leakage may develop when an application or other software program reserves memory for an instance of a class (e.g., classes having collections and/or arrays of objects) but then does not clean or release the reserved memory to the operating system. For instance, in some situations, a memory leak or memory leakage may transpire when an object is stored in memory and may be accessible by code when not needed anymore, thus preventing the object from being garbage collected. Further, since memory leaks have potential for exhausting available system memory during code execution, memory leaks may thus cause or at least contribute to diminished performance, efficiency, and reliability.

In an example, production environment may describe an implementation of software applications and programs into operation for their intended purpose and use by users including administrators and operators. For instance, a production environment may be referred to as a real-time setting where software applications and programs are executed to interface with hardware operations.

In an example, a class may be considered a construct used for creating instances of itself, which may be referred to as instances and/or objects, and a class may be configured to define members that enable its instances and/or objects to have state and behavior. These members may include data field members (e.g., member variables or instance variables) that enable a class instance to maintain state, and other types of members may enable behavior of class instances. Further, a class may be configured to define a type of their instances, wherein the type may include classification for identifying a type of data, operations that may be performed on values of the type of data, and a manner in which values of that type of data may be stored. In some examples, classes may be represented as blocks in object-oriented programming languages, such as Java, and these blocks may be referred to as blueprints of what objects look like.

In an example, objects may include data and one or more processes for using the data, wherein objects may refer to data structures along with their associated processing routines. In some examples, objects may be considered instances of classes, wherein classes may define properties and behavior for multiple instances thereof. As such, an object may include set of specific properties, attributes, behaviors, etc., and objects need to be constructed. Further, objects are used in object-oriented programming and related software development as abstract data structures to integrate data with processes to manipulate the data. For example, objects in object-oriented programming are used for inheritance to thereby improve program integrity and reliability.

In an example, a container may include a class (containing class) having members that are collections of other objects. As such, containers (containing classes) may be used for storing objects in an organized manner, and thus, containers (containing classes) may be utilized to hold collections of objects. The size of the container (containing class) may depend on a number of “contained” objects. Therefore, depending on the size and processes for implementing the “contained” objects, a container (containing class) may achieve active growth in size or actively diminish in size, which may affect the reliability and efficient use of the container (containing class).

In the example ofFIG. 1, the collection sizes tracker120may include an instrumentation manager122configured to identify which of the one or more containing classes hold at least one static or non-static field of collection or array type. In an implementation, the instrumentation manager122may be configured to modify code for the one or more containing classes that hold at least one static or non-static field of collection or array type. Further, the one or more fields of each containing class may be configured to enable instances of each containing class to maintain at least one of state and behavior. In an implementation, instrumentation may refer to an ability to monitor or measure a level of performance to diagnose errors and trace information. In another implementation, instrumentation may be implemented in a form of code instructions that may be configured to monitor or measure specific components or operations in a system and further used to review performance of an application. In another implementation, instrumentation may be considered an industry term that may refer to modifying a class at run time, such as, for example, by either changing instructions of methods and/or their behavior or, in another example, by modifying the classes' fields.

In an example, data having multiple parts, elements, or components may be divided into multiple fields or filed members. Further, data may be arranged as sets of database records, wherein each record may include multiple fields. In some examples, a field (which may be referred to as a data member or member variable) may include data contained within a class instance or an object. In various examples, static fields may be associated with a class, and static fields may not be associated with an object of the class, wherein a static field may be initialized when the class is loaded at runtime. In various other examples, non-static fields may be instance fields of an object, and non-static fields may only be accessed or invoked through an object reference. Further, a value of a static field may remain constant throughout the class, and a value of a non-static field may change as objects may have their own instance of these fields.

In various examples, when a field is static, a same field, memory location, and value may be used for all instances of a class. This field may be created once per class. When a field is not static, a different memory location may be used for each of the class's instances. Each instance field may hold a different value. The field may be created once per instance. Aspects of the disclosure are related to tracking containing class(es) and periodically sampling static Collection/array fields' sizes of each tracked class. Aspects of the disclosure are also related to tracking containing class's instances. For each instance, non-static Collection/array fields sizes may be sampled.

In various examples, a collection may be referred to as a grouping of any number of data items that may have a shared significance to working a problem in a controlled manner. The data items may be of a same type and may be derived through inheritance. In some examples, a collection may be include abstract data types, and types of collections may include one or more of lists, sets, multi-sets, trees, graphs, etc.

In an example, an array type may be referred to as a data type that may be configured to describe a collection of elements (e.g., values or variables). In an array type, each element may be selected by one or more indices that may be determined or identified at time of execution by a software application or program. Such a collection may be referred to as an array variable, array value, or an array. In some examples, a fixed-size array may or may not be considered a collection due to holding a fixed number of data items, and a variable-sized array may be considered a collection.

In the example ofFIG. 1, the collection sizes tracker120may include a polling mechanism124configured to access the one or more containing classes that hold the at least one static or non-static fields of collection or array type and track a size for each field of each containing class by periodically sampling size data of each field over an interval (e.g., any number of seconds, minutes, etc.). The size may include any number of objects held by the static or non-static field of collection or array type.

In an implementation, the polling mechanism124may be configured to search for and discover one or more containing classes including class instances (objects) having at least one static or non-static field of collection or array type. In an example, an instance (or class instance) may refer to an occurrence or a copy of an object, and instances of a particular class may share one or more attributes. Further, in another example, a description of a class may list or itemize attributes and define one or more operations, actions, and/or processes relevant for the class.

In an implementation, the polling mechanism124may be configured to stop tracking the one or more fields of each containing class that do not exhibit suspect behavior in the size over the interval. Further, the polling mechanism124may be configured to stop tracking classes and/or instances thereof that do not show memory leak behavior or characteristics, including uninteresting classes and/or instances thereof, such as, for example, classes and/or instances thereof that attenuate or do not show any significant growth in their collections.

In an implementation, the polling mechanism124may be configured to track only the containing classes having the at least one static or non-static fields of collection or array type. For instance, the polling mechanism124may utilize memory leak detection to identify containing classes (containers) having collections that exhibit suspect behavior, such as constant growth in size, and mark these collections as having potential memory leaks. Other containing classes (containers) not exhibiting this suspect behavior over a number of periodic size samples may be discarded or at least no longer tracked, and as such, their collections sizes may not be polled anymore. Further, in some implementations, the polling mechanism124may be configured to determine a baseline memory usage for classes and/or instances thereof that may be used to detect abnormal behavior in terms of memory consumption.

In an implementation, the polling mechanism124may be configured to analyze the suspect behavior in the size of the one or more containing classes by testing each static or non-static field of collection or array type of each containing class for constant growth behavior over the interval including a periodic interval to detect suspected memory leaks that result from constant growth of each static or non-static field of collection or array type. Further, the polling mechanism124may be configured to track only specific containing classes that exhibit constant growth behavior of the size (or size data) over the periodic interval.

In an implementation, the collection sizes tracker120(or, in another implementation, the instrumentation manager122) may be configured to analyze (via the polling mechanism124) each class including each containing class and look for fields (members) that are collections or that are array types. If there are no such fields, then the class is not considered interesting and may be ignored. However, if there are such fields (either static or non-static), than the class is considered interesting, and this interesting class and its fields of collection or array type may be kept or held (with weak references so that this class may be garbage collected when necessary).

In accordance with aspects of the disclosure, if the size of one or more objects in a class are increasing in size, then these objects in this class may be considered interesting, and these objects may be considered as suspect for memory leaks. Further, if the size of one or more objects in a class are decreasing in size, then these objects in this class may be considered uninteresting or non-interesting, and these objects may not be considered as suspect for memory leaks.

In the example ofFIG. 1, the collection sizes tracker120may include an algorithm handler126configured to process the size data for each field of each containing class from the polling mechanism124and detect suspected memory leaks of each containing class by identifying which of the one or more fields of each containing class exhibits suspect behavior in the size over the interval. In an implementation, processing the size data for each field of each containing class may include acquiring the size or size data for each field of each containing class. The algorithm handler126may be configured to mark the one or more fields of each containing class that are identified to exhibit suspect behavior in the size over the interval.

In an implementation, identifying which of the one or more fields of each containing class exhibit suspect behavior may include identifying which of the one or more fields of each containing class exhibits constant growth behavior in the size over the interval. Further, identifying which of the one or more fields of each containing class exhibit suspect behavior may include identifying which of the one or more fields of each containing class are suspected of exhibiting a potential growth trend. In some examples, the algorithm handler126may not specifically identify constant growth, and as such, the algorithm handler126may be configured to identify which classes and/or instances thereof exhibit behavior making it a candidate for a source of memory leak.

In the example ofFIG. 1, the collection sizes tracker120may include a storage handler128configured to store information for, or at least relating to the one or more containing classes. For instance, the storage handler128may be configured to store information for each containing class having suspected memory leaks. In another instance, the storage handler128may be configured to store information for each of the one or more fields of each containing class that are identified to exhibit suspect behavior in the size over the interval. In another instance, the storage handler128may be configured to store information for each result that pinpoints a suspected memory leak to a specific field in a specific containing class. In various implementations, the storage handler128may be configured to store information in various memory components, such as, for example, the memory112and/or the one or more optional database(s)140.

In an implementation, the collection sizes tracker120may be configured to identify or determine a suspected memory leak metric by estimating the size of the memory that is suspected as a leak. Referring to escalation, when identifying a growing trend in the memory usage metric, the interval between periodic size samples may be adjusted (e.g., raised or lowered), and any amount of data may be kept or stored.

Further, the collection sizes tracker120may be configured to provide a collection tracking view for providing information of collections exhibiting suspect behavior, such as, for example, constant growth. The collection sizes tracker120may be configured to provide the collection tracking view via the display device150and include any relevant information related to suspect behavior.

In accordance with aspects of the disclosure, the collection sizes tracker120may be configured to find classes that have collection and/or array type fields, track these classes' collection field sizes, and identify possible or potential memory leaks by, for example, identifying a growing trend (e.g., increasing field sizes) in a memory usage metric for each class, each class instance, and/or each class object. As such, any impact on performance may be low, since in some examples, the collections sizes tracker120may only be tracking specific instances of specific classes that exhibit or show growth (e.g., increasing field sizes), wherein if an instance is not exhibiting or showing growth (e.g., static or decreasing field sizes), then tracking may be no longer needed and stopped or terminated.

Further, in the example ofFIG. 1, the collection sizes tracker120may be configured to use various other types of data stored in the optional database140related to class and/or instances thereof including containing classes and containing class instances thereof, which may be known or thought to influence, control, and/or otherwise constrain operations of the collections sizes tracker120and components thereof. It should also be appreciated that any example data is intended merely as non-limiting examples, and any additional and/or alternative types of data may be used in the operations of the collection sizes tracker120. For instance, data may be stored, e.g., in the one or more optional databases140and/or elsewhere including the memory112.

In the example ofFIG. 1, it should be appreciated that the memory leak detection system100is shown using various functional blocks or modules that represent more-or-less discrete functionality. However, such illustration is provided for clarity and convenience, and therefore, it should be appreciated that the various functionalities may overlap or may be combined within a described block(s) or module(s), and/or may be implemented by one or more block(s) or module(s) not specifically shown in the example ofFIG. 1. Generally, it should be appreciated that conventional functionality that may be considered useful to the system100ofFIG. 1may be included as well even though such conventional elements are not shown explicitly, for sake of clarity and convenience.

FIG. 2is a process flow illustrating an example method200for memory leak detection, in accordance with aspects of the disclosure.

In the example ofFIG. 2, operations202-212are illustrated as a series of discrete operations occurring in sequential order. However, in other implementations, two or more of the operations202-212may occur in a partially or completely overlapping or parallel manner, or in a nested or looped manner, or may occur in a different order than that shown. Further, additional operations, that may not be specifically shown in the example ofFIG. 2, may be included in some other implementations, while, in still other implementations, one or more of the operations202-212may be omitted.

Moreover, in various other implementations, the method200may include a process flow for a computer-implemented method for memory leak detection in the system100ofFIG. 1. Further, as described herein, the operations202-212may provide a simplified operational process flow that may be enacted by the computer device104to provide features and functionalities as described in reference toFIG. 1.

In the example ofFIG. 2, at202, the method200may include monitoring one or more classes (containers or containing classes) in a production environment. In an implementation, the method200may be configured to look at (e.g., observe and/or survey) classes to determine which class(es) may be considered “interesting” classes or containing classes that should be followed or monitored. At204, the method200may include identifying which of the one or more containing classes hold at least one static or non-static field of collection or array type. At205, the method200may include, after recognizing a class as interesting, instrumenting its constructors to register the class with the CollectionSizesTracker class. This may include use of an instrumentation bit. At206, the method200may include accessing the one or more containing classes that hold the at least one static or non-static fields of collection or array type.

Further, at208, the method200may include tracking a size for each field of each containing class instance by periodically sampling the size data of each field over an interval. In an example, the one or more fields of each containing class enabling instances of each containing class to maintain at least one of state and behavior. At210, the method200may include processing the size data for each (static or non-static) field of each containing class. In an implementation, processing the size data for each (static or non-static) field of each containing class may include acquiring and/or receiving the size or size data for each (static or non-static) field of each containing class. At212, the method200may include detecting suspected memory leaks of each containing class by identifying which of the one or more fields of each containing class exhibits suspect behavior in the size over the interval.

In an implementation, the method200may include modifying code for the one or more containing classes that hold at least one static or non-static field of collection or array type. The size may include a number of objects held by the static or non-static field of collection or array type. Further, identifying which of the one or more fields of each containing class exhibit suspect behavior may include identifying which of the one or more fields of each containing class exhibits constant growth behavior in the size over the interval. Still further, identifying which of the one or more fields of each containing class exhibit suspect behavior may include identifying which of the one or more fields of each containing class are suspected of exhibiting a potential growth trend.

In an implementation, the method200may include searching for and discovering the one or more containing classes including class instances and class objects having the at least one static or non-static fields of collection or array type. Further, in another implementation, the method200may include storing information for, or at least related to, the one or more containing classes. For example, the method200may include storing information for each containing class instance having suspected memory leaks. In another example, the method200may include storing information for each of the one or more fields of each containing class instance that are identified to exhibit suspect behavior in the size over the interval. The method200may further include storing information for each result that pinpoints a suspected memory leak to a specific field in a specific instance of a specific containing class.

In an implementation, the method200may include storing information for or at least related to the one or more classes (containers or containing classes) including monitoring, identifying, accessing, tracking, processing, acquiring, receiving, and/or detecting various aspects of each class (container or containing class) in relation to performing the operations202-212of the method200.

The described process of the method200in the example ofFIG. 2may be configured to detect memory leaks that may result from growth of collection fields or array type fields by tracking their sizes through the containing classes. This way, in some examples, only the classes identified to contain collections or arrays may be tracked. The sizes of the collection and/or arrays may be tracked and checked periodically with less impact on performance. These periodical size samplings may be used by an algorithm for deciding if there is a possible or potential memory leak. The output of this process may be the potential memory leaks with information regarding not only the collection and/or array that is suspect, but regarding the containing class and the specific instance containing the field suspected of being a memory leak.

FIG. 3is a process flow illustrating another example method300for memory leak detection, in accordance with aspects of the disclosure.

In the example ofFIG. 3, operations302-306are illustrated as a series of discrete operations occurring in sequential order. However, in other implementations, two or more of the operations302-306may occur in a partially or completely overlapping or parallel manner, or in a nested or looped manner, or may occur in a different order than that shown. Further, additional operations, that may not be specifically shown in the example ofFIG. 3, may be included in some other implementations, while, in still other implementations, one or more of the operations302-306may be omitted.

Moreover, in various other implementations, the method300may include a process flow for a computer-implemented method for memory leak detection in the system100ofFIG. 1. Further, as described herein, the operations302-306may provide a simplified operational process flow that may be enacted by the computer device104to provide features and functionalities as described in reference toFIG. 1.

In the example ofFIG. 3, at302, the method300may include marking the one or more fields of each containing class that are identified to exhibit suspect behavior in the size over the interval. At304, the method300may include analyzing the suspect behavior in the size of the one or more containing classes by testing each static or non-static field of collection or array type of each containing class for constant growth behavior over the interval including a periodic interval to detect suspected memory leaks that result from constant growth of each static or non-static field of collection or array type. In some implementations, the method300may utilize an algorithm that is simple and efficient; however, in some other implementations, another more elaborate algorithm may be utilized to establish a normal baseline usage and identify abnormalities. At306, the method300may include tracking only specific containing classes that exhibit constant growth behavior of the size over the periodic interval.

In an implementation, the method300may include storing information for or at least related to the one or more containing classes including marking, analyzing, testing, and tracking various aspects of each containing class in relation to performing the operations302-306of the method300.

FIG. 4is a process flow illustrating another example method400for memory leak detection, in accordance with aspects of the disclosure.

In the example ofFIG. 4, operations402-406are illustrated as a series of discrete operations occurring in sequential order. However, in other implementations, two or more of the operations402-406may occur in a partially or completely overlapping or parallel manner, or in a nested or looped manner, or may occur in a different order than that shown. Further, additional operations, that may not be specifically shown in the example ofFIG. 4, may be included in some other implementations, while, in still other implementations, one or more of the operations402-406may be omitted.

Moreover, in various other implementations, the method400may include a process flow for a computer-implemented method for memory leak detection in the system100ofFIG. 1. Further, as described herein, the operations402-406may provide a simplified operational process flow that may be enacted by the computer device104to provide features and functionalities as described in reference toFIG. 1.

In the example ofFIG. 4, at402, the method400may include marking the one or more fields of each containing class that are identified to exhibit suspect behavior in the size over the interval. At404, the method400may include stopping tracking of the one or more fields of each containing class that do not exhibit suspect behavior in the size over the interval. At406, the method400may include tracking only the containing classes having the at least one static or non-static field of collection or array type.

In an implementation, the method400may include storing information for or at least related to the one or more containing classes including marking and tracking (including stopping the tracking of) various aspects of each containing class in relation to performing the operations402-406of the method400.

FIG. 5is a process flow illustrating another example method500for memory leak detection, in accordance with aspects of the disclosure.

In the example ofFIG. 5, operations501-508are illustrated as a series of discrete operations occurring in sequential order. However, in other implementations, two or more of the operations501-508may occur in a partially or completely overlapping or parallel manner, or in a nested or looped manner, or may occur in a different order than that shown. Further, additional operations, that may not be specifically shown in the example ofFIG. 5, may be included in some other implementations, while, in still other implementations, one or more of the operations501-508may be omitted.

Moreover, in various other implementations, the method500may include a process flow for a computer-implemented method for memory leak detection in the system100ofFIG. 1. Further, as described herein, the operations501-508may provide a simplified operational process flow that may be enacted by the computer device104to provide features and functionalities as described in reference toFIG. 1.

In the example ofFIG. 5, the process of method500may be configured to detect memory leaks that may result from growth of collections and/or arrays by tracking their sizes through the containing classes holding them. As such, in an example, only the containing classes identified to contain collections and/or arrays are tracked. In some examples, the sizes of the collections and/or arrays may be checked periodically without negatively impacting performance. These periodical size samplings may be used as input to an algorithm for determining if there is a possible memory leak. The output of this process may provide information related to potential memory leaks including information relating to not only the collection and/or array that may be suspect (i.e., suspected of memory leaks), but also relating to the containing class and related instances. In various examples, aspects of the disclosure may be configured to build on the existence of byte code instrumentation infrastructure.

In the example ofFIG. 5, at501, the method500may include class load in reference to an instrument static initializer. For instance, on class load, the process may be configured to modify a static initializer (or generate the static initializer, if none exists) to register a class or classes (including user classes) with modified code for identifying one or more classes that may have potential memory leaks.

At502, the method500may include instrumentation of a static initializer, and further at502, the method500may include using the static initializer to register the class(es) with modified code. For instance, when code in a class's static initializer is executed, it may register itself with the modified code. In an example, it may register the class in a CollectionSizesTracker class, which may be a singleton. Further, when the class is initialized, the modified static initializer may register the class in an agent. In another example, after recognizing that a class is interesting, the method500may include instrumenting its constructors to register the class with the CollectionSizesTracker class, which may include utilizing an instrumentation bit.

At503, the method500may include checking for collection and/or array members in the registered class(es). For instance, the CollectionSizesTracker class or the instrumentation manger may be configured to analyze the class(es) and look for members that are either assignable to a collection interface or that are array types. In an example, if such fields are non-existent, then the class is not considered interesting and may be ignored. In another example, if there are such fields (either static or not), than the class is considered interesting, and it and its collection/array fields may be accessed per instance (e.g., with weak references so that this class may be garbage collected, when necessary). Further, in another example, the class's fields or members may be tested to see if there are collection fields in it.

At504, the method500may include applying, implementing, and/or using instrument constructors. For instance, if the class (e.g., containing class) was considered interesting, then its constructors may be instrumented to register any newly created or generated instance of this class with the CollectionSizesTracker class.

At505, the method500may include a constructor for registering instances of the class(es). For instance, when the instrumented constructor's code is executed, it may register the new instance(s) with the CollectionSizesTracker class, whereby a (weak) reference to the newly created instance may be kept, as described herein. Further, when an object of a class is created, the instrumented constructor may register the instance.

At506, the method500may include poll sizes or polling a size of the collection and/or array of each class including containing class. For instance, the process may be configured to go through all classes registered in the CollectionSizesTracker class and check the sizes of the collection and/or array static fields. In another instance, the process may be configured to go through all registered instances of each class and check the sizes of the non-static fields, of collection and/or array type. Further, the sizes of all the collection fields of each class may be periodically tested for suspect behavior, such as, for example, increasing growth, including constant growth or varying growth.

At507, the method500may include applying logic. For instance, in the current sample and/or previous samples, the process may be configured to determine, decide, and/or identify which class instances are not interesting and should not be tracked any further. As such, uninteresting or non-interesting class instances may no longer be tracked, and therefore, tracking of these instances or classes that do not show memory leak characteristics or behavior may be stopped. In another instance, the process may be configured to indicate which classes and/or instances of classes that, according to a tracked time interval and size samples, are interesting and suspect of showing growth.

In an implementation, the apply logic operation507may be configured to provide a basic algorithm intended to detect memory leaks. For instance, the algorithm for memory leak detection may be configured to identify containers (containing classes) instances with collections and/or arrays that exhibit suspect behavior (e.g., constant growth) in size and mark these identified containers (containing classes) as potential memory leaks. In another instance, other containers (containing classes), not showing suspect behavior over a few samples, may be discarded, and their sizes may not be polled any further.

At508, the method500may include further poll sizes or further polling size(s) of the collection(s) and/or array(s) of class(es) including containing class(es). For instance, the process may be configured to wait a selectively configurable time interval (e.g., any periodic time interval including, for example, second(s), minute(s), etc.) and go back to operation or stage506. In an implementation, by repetitively running through operations506,507,508, the CollectionSizesTracker class may be configured to hold, at any time, the list of classes/instances that may be suspect of being a memory leak.

In an implementation, according to the example ofFIG. 5, the method500may include a polling process or a polling mechanism that may be configured to enable processing (e.g., acquiring, receiving, etc.) classes (containers or containing classes) and may be configured to further enable polling of their static or non-static field sizes of collection or array type. Further, according to the example ofFIG. 5, the method500may include an algorithm process or algorithm handler that enables detecting memory leaks from the polled sizes data. In some other implementations, the algorithm may be replaced by any other algorithm that uses sampled collection sized data and allows for addressing a broader set of problems and not only memory leak detection.

Further, in another implementation, the method500may be configured to determine a baseline memory usage for classes and/or instances and to detect abnormal behavior in terms of memory consumption. The method500may be further configured to provide results pinpointing one or more problems associated with a specific field of collection or array type in a specific class instance.

Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

To provide for user interaction, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other types of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input.