Methods and systems for memory suspect detection

A processor-implemented method for memory suspect detection, comprising:

• systematically executing, via one or more hardware processors, a plurality of transactions of an application to generate metrics, the plurality of transactions associated with suspected memory allocations, the suspected memory allocations associated with one or more of classes known for common memory issues, classes associated with memory issues from previous executions, and classes associated with user interest, wherein the classes and binaries of the application satisfy at least one predefined criteria;
• implementing, via the one or more hardware processors, binary execution logics in the application based on the generated metrics, while tracking one or memory allocation requests from the application to a runtime environment;
• establishing, via the one or more hardware processors, a memory monitoring session with a server, wherein the application is monitored in a controlled environment with systematic execution of application use-cases, wherein a plurality of memory snapshots is at least one of user triggered and auto configured and wherein the plurality of memory snapshots are categorized based on the application use-cases and the plurality of memory snapshots contain relevant application context to identify at least one of the application use-cases and the plurality of transactions;
• periodically capturing, via the one or more hardware processors, the metrics generated while systematically executing the plurality of transactions during the monitoring session as the plurality of memory snapshots of each of the plurality of transactions, the metrics generated on execution of one of the plurality of transactions comprises memory allocation information and application memory information associated with the one of the plurality of transactions, wherein the memory allocation information comprise a memory allocation type, a timestamp, a size, and an origin of memory allocation, wherein the metrics are referred to as memory snapshots that are captured at the beginning and at the end of a memory monitoring session termed as baseline snapshots and during the memory monitoring session termed as intermediate snapshots, wherein the memory allocation type comprises a structure and a class, and wherein the application memory information comprise information associated with memory utilized by the application, a number of attempts made by the runtime environment to clean memory, time spent to clean the memory, timestamp of capturing the metrics;
• tagging via the one or more hardware processors, each of a plurality of memory allocation requests with a corresponding unique identifier, wherein the unique identifier associated with a memory allocation request of the plurality of memory allocation requests comprises a hash code of a corresponding allocated memory location, type of object created in response to the memory allocation request, a timestamp of creation of the object, and location of source code from where the memory allocation request is originated, wherein a location of the object is defined as a function of at least one of a thread, a class, a classloader, a method and a line number;
• dynamically updating, via the one or more hardware processors, the generated metrics based on usage of the plurality of transactions;
• parsing, via the one or more hardware processors, the updated metrics across the plurality of memory snapshots captured during the monitoring session to generate a memory suspect list;
• performing analytics on the periodically captured metrics of each of the plurality of transactions to determine a change in count and size of each type or class of memory allocations by parsing the metrics across the memory screenshots to generate a memory suspect list, wherein for each of the memory allocation information, a comparison is made between multiple memory snapshots to determine change in count, size of each type or class of objects;
• identifying, via the one or more hardware processors, a set of transactions from amongst the plurality of transactions impacted due to the suspected memory allocations based on the change in count and size of each type or class of memory allocations, and a graphical pattern is generated for all object types which have a net increase in overall memory size or count in comparison with a baseline start snapshot and a baseline end snapshot, wherein a slope is computed for the graphical pattern by considering multiple point along the graphical pattern in which the object types with highest average positive slope values and no negative slopes are listed in descending order, wherein if the slope is zero or negative or a combination of positive and negative with a net trend of negative, then the object types are not categorized as memory suspects, wherein if the slope is linear and positive or the net combined average slope is positive, then the object types are candidates for memory suspects;
• isolating, via the one or more hardware processors, a location of each of the suspect memory allocations to generate one or more trends of memory, based on at least one of memory usage, garbage collections and the application use-cases;
• associating each of the suspected memory allocations with reference to one of the plurality of transactions;
• and
• profiling, via the one or more hardware processors, each of the suspect memory allocations by implementing the binary execution logics in a target application to track the plurality of memory allocation requests from the target application to the run time environment.