Memory allocation tracking

The subject disclosure relates to tracking and/or auditing memory allocations for one or more computer-implemented processes. In particular, memory allocation commands as well as memory free commands, both native and managed, can be intercepted. As such, a tag can be created that can be associated with a particular memory allocation. This tag can include various information that can more robustly describe the current state of system memory. Moreover, the tag can be deleted as an associated memory free command is received. Thus, as memory is freed and therefore no longer relevant to the current state of system memory, such does not clutter present examination.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to co-pending U.S. patent application Ser. No. 13/217,224 entitled, “MEMORY ALLOCATION ANALYSIS”, filed on Aug. 24, 2011, and to co-pending U.S. patent application Ser. No. 13/216,275 entitled, “AUTOMATIC MEMORY LEAK DETECTION”, filed on Aug. 24, 2011, the entireties of each of which applications are incorporated herein by reference.

TECHNICAL FIELD

The subject disclosure generally relates to tracking computer system memory that is allocated by processes or modules running on a computer.

BACKGROUND

In the domain of software application development, a prolific difficulty is avoidance of memory leaks. Memory leaks can lead to inefficient use of system resources, if not instability of the system or a particular application executing thereon. When attempting to detect a memory leak, a particular scenario might repeat multiple times, with perhaps millions of memory allocations and associated memory releases or “frees”. Call stacks collected for native memory allocations must be manually matched with their associated memory free, since unmatched memory that was not freed could constitute a leak.

Engaging in the matching process constitutes an enormous amount of labor that currently must be accomplished manually, by a developer. Moreover, once done, even if accurately so, finding a memory leak is still problematic and requires analysis of huge amounts of data. Moreover, this process is particularly difficult in a garbage collected (e.g., “managed”) system where there are no explicit memory frees. Furthermore, unmatched leftover memory allocations are to be associated with scenario iteration. A pattern of allocations per iteration, such as 23 identical allocations, could be a leak, but might not be.

There are many software utilities or tools intended aid in this process, for example, by presenting various information known about the current or historic state of system memory. One such tool is User Mode Dump Heap (UMDH), which is described at http colon slash slash support dot Microsoft dot com slash kb slash 268343. UMDH can record the call stack of heap allocations. Thus, for each unique stack, UMDH will total the memory allocations. Typically, UMDH operates by running a particular scenario twice to get two related UMDH dumps. From these two scenarios, the differences between them will show which memory allocations and totals were made between the two iterations. However, UMDH has numerous shortcomings. In particular, UMDH is not applicable beyond native memory calls, and thus is not useful in the case of managed or non-native calls. Secondly, UMDH is not an interactive tool, but rather is useful for post-scenario analysis instead. Third, UMDH is not capable of identifying certain inefficient memory usage, but rather aids in detecting memory leaks instead. Fourth, UMDH is not compatible with certain types of memory allocation commands, such as VirtualAlloc, mapped files, or as noted, managed code.

Another memory tool is WinDbg and Visual Studio debugger extension called SOS.DLL, which is detailed at http colon slash slash msdn dot Microsoft dot com slash en dash us slash library slash bb19074 dot aspx. SOS.DLL allows a user to dump the managed heap. From that dump, one can view counts and references of various managed objects. However, SOS.DLL does not utilize call stacks and further is not compatible with native memory calls, but rather managed memory calls instead. As such, SOS.DLL can give many false positives in connection with leak detection, especially if no garbage collection has yet occurred.

A third tool is Common Language Runtime (CLR) Profiler. CLR Profiler allows a user to see managed objects, but has no native memory allocations components.

The above-described deficiencies of today's techniques are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.

SUMMARY

In one or more embodiments, the disclosed subject matter relates to an architecture that can facilitate robust tracking and/or auditing of allocated computer system memory. In accordance therewith, the architecture can include an intercept component that can be configured to intercept a memory call from at least one process that allocates computer memory or releases computer memory. Typically, the memory call is a memory allocation instruction or a memory release instruction, and it is noted that in either case, the memory call can be explicitly called by native instructions or called in accordance with managed instructions.

In addition, the architecture can include a record component configured to create and store a tag in response to interception of the memory allocation instruction. Generally, the tag can include a call stack associated with the at least one process, an allocation size of the memory allocation instruction, a thread identification, and a tag sequence number. Furthermore, the architecture can include a matching component that configured to delete the tag in response to a matching memory release instruction. Hence, memory included in the tags will relate to memory that is currently allocated by the at least one process.

Moreover, in one or more embodiment, the architecture can provide a method for intercepting a memory transaction from at least one process that allocates computer memory or frees computer memory, wherein the memory transaction is a memory allocation command or a memory free command.

The method can further provide creating a tag in response to intercepting the memory allocation command and for including in the tag a call stack associated with the at least one process, an allocation size of the memory allocation, a thread identification, and a tag sequence number. Likewise, the method can provide for storing the tag to a private memory heap and deleting the tag in response to a matching memory free command.

In still another embodiment, the architecture can include an intercept component stored in a computer readable storage medium configured to intercept memory allocation calls and memory release calls from at least one process that allocates computer memory or frees computer memory according to either managed commands or native instructions. The intercept component is further configured to allocate memory in accordance with the memory allocation calls.

The architecture can further include a record component configured to create and store a tag in response to interception of at least one memory allocation call. The tag includes a call stack associated with the at least one process, an allocation size of the memory allocation instruction, a thread identification, and a tag sequence number. Likewise, the architecture can include a matching component configured to delete the tag in response to a corresponding memory release call. The matching component is further configured to release the memory in accordance with the memory release call.

DETAILED DESCRIPTION

Overview

By way of an introduction, the subject matter disclosed herein relates to various embodiments relating to comprehensively tracking and/or auditing of computer-based memory allocations. In particular, the subject matter can provide a mechanism to intercept certain memory transactions or calls, such as, e.g., memory allocations or memory releases or “frees”. Such memory transactions can originate from either native code or from managed code, for example, from the process or a related process or thread that provides for the allocation or from a garbage collection process or routine. Of these memory transactions, those that represent allocations can be recorded by way of an associated tag that stores information relating to a particular memory allocation instruction (e.g., the type of allocation, the entity issuing the instruction, the amount of memory, . . . ).

Generally, if a corresponding memory release or free instruction is intercepted, then an associated tag is also freed as well, thus eliminating the need for manually matching items when viewing information associated with memory and/or call stacks. It is noted that removing tags in connection with memory release commands can be more straightforward when the release command is explicitly issued by native code than when occurring in connection with garbage collection routines in which no explicit release call is provided by the native code, but is instead ordered according to inherent memory protocols. Thus, the disclosed subject matter can track objects or other memory allocations throughout any garbage collection operation in order, e.g., to determine whether the memory allocation is indeed garbage or to associate the memory allocation that has been moved (e.g., due to a defragmentation operation) by a garbage collection operation with the original memory allocation tag.

In order to effectuate certain memory tracking elements, the disclosed subject matter can record a call stack associated with any given memory allocation instruction, and place that information in the associated tag. Along with the call stack, memory allocations can also be tagged with a thread ID, a sequence number (e.g., 0, 1, 2, 3 . . . ) as well as other pertinent information. It is thus noted that data included in a given tag can enable ready recognition of how leftovers are distributed in time with the scenario iteration. For example, if there are 321 allocations per iteration, one can be instantly apprised of a likely memory leak.

In addition, as introduced above, various objects or other memory allocations can be tracked through garbage collection operations. These allocations can also be tagged with a number of times an object has survived or moved in a garbage collection operation as well as the particular garbage collection generation of the object (e.g., Gen 0, Gen 1, . . . ), which can provide more robust features in connection with managed memory constraints.

Tracking Memory Allocations

Referring now to the drawings, with reference initially toFIG. 1, system100that can track computer-based memory allocation is depicted. Generally, system100can include intercept component102that, as with all components described herein can be stored in a computer readable storage medium. Intercept component102can be configured to intercept memory call104from at least one process106. The at least one process106can be in active execution by operating system108, which can be coupled to and/or provide administration of memory110. Hence, the at least one process106can issue memory call104for the express purpose of allocating computer memory110or releases computer memory110. Thus, it is noted that memory call104can encompass either or both memory allocation instruction112or a memory release instruction114, depending upon whether process106orders a memory allocation or a memory release (or “free”). These and other features are depicted with reference toFIGS. 2A and 2B.

For example, while still referring toFIG. 1, but turning now as well toFIGS. 2A and 2B,FIG. 2Aillustrates various examples of process106, whereasFIG. 2Bprovides various examples of memory call104. With particular reference toFIG. 2A, process106can be associated with, e.g., substantially any application202. For instance, application202can be a suite of related applications, a stand-alone application, one or more integrated development environment (IDE) applications and so forth. Moreover, process106can be associated with one or more add-in application, a module such as a dynamic linked library (DLL), or helper application204or an application or instance subsequently invoked by application202. Likewise, another example of at least one process106can be thread206invoked or otherwise related to application202or helper application204. Additionally or alternatively, example process106can relate to garbage collection process208or some other managed process or operation.

Referring particularly toFIG. 2B, four example memory call104types are illustrated. As introduced above, in the first case, an example of memory call104can be memory allocation call112. In the second example, memory call104can be memory release (or free) call114. In addition, various garbage collection instructions can be intercepted as well, such as garbage collection (GC) Start210and GC Finish212, which are further discussed infra.

Still referring toFIG. 1, it is noted that while intercept component102can intercept memory call104, in one or more aspect, intercept component102can further forward or pass memory call104to its originally intended destination, generally OS108or to a heap or other relevant portion of a file system (not shown). Thus, operation of system100can be substantially transparent to process106. Whether intercept component102forwards memory call104or otherwise facilitates suitable allocation of the expected memory, such is generally accomplished with as little delay or latency as possible. For example, memory call104can be intercepted, rapidly processed, and immediately forwarded. As another example, memory call104can be intercepted, copied to a register or cache and immediately forwarded with the copy temporarily available for processing thereafter.

Hence, in one or more aspect intercept component102can be further configured to allocate memory (e.g., by forwarding memory call104) in accordance with memory allocation instruction112that was previously intercepted. Likewise, in one or more aspect intercept component102can be further configured to release memory in accordance with memory release instruction114that was previously intercepted.

In addition, system100can further include record component116configured to create and store tag118in response to interception of memory allocation instruction112(e.g., one particular type of memory call104). In particular, tag118can include a call stack associated with at least one process106, an allocation size of memory allocation instruction112, a thread identification, and a tag118sequence number. It is noted that tag118can also be constructed to include other suitable data as well. In one or more aspect, tag118can be stored to private heap120, which can be a portion of memory110specifically allocated for use by the disclosed subject matter. Additional detail in connection with private heap120is detailed infra.

Furthermore, system100can include matching component122that can be configured to delete tag118in response to a matching memory release instruction114. For example, when a given tag118is created by an initial memory allocation instruction (e.g.,112), then a subsequent memory release instruction (e.g.,114) associated with the memory allocated by the initial memory allocation instruction can prompt matching component122to delete an associated tag. Hence, memory that was previously allocated, but later freed need not be included in any examination of currently allocated memory for the at least one process106. As such, when examining currently allocated memory, users are not required to manually match or offset initial allocations with subsequent memory releases in order to identify or track potential memory leaks or to perform other analyses.

As discussed supra, memory call104(e.g., memory allocation instruction112or memory release instruction114) can be configured in accordance with either or both native models where freeing previously allocated memory is explicitly provided or managed models where freeing previously allocated memory is handled by preconfigured entities designed for such purposes, such as garbage collection operations. Accordingly, the described subject matter can operate according to various configurations, scenarios, and/or embodiments, some of which are further detailed with reference toFIGS. 3-5.

While still referring toFIG. 1, but turning now as well toFIGS. 3-5, various aspects relating to native and managed memory calls are provided. In particular,FIG. 3discloses system300in which a memory release call is received from the same process that previously allocated the associated memory. Thus, system300includes intercept component102illustrated to intercept memory allocation112explicitly called by process106. In addition, intercept component102subsequently intercepts an associated memory release call (e.g.,114) explicitly called by process106.

Similarly,FIG. 4discloses system400in which a memory release call is received from a different process than the process that previously allocated the associated memory. Thus, system400includes intercept component102illustrated to intercept memory allocation112explicitly called by process106. However, it is appreciated that in many cases, a particular process that allocates memory can do so for consumption by another process, such as a child process or another related process or thread, denoted here as related process402. In such cases, intercept component102can subsequently intercept an associated memory release call (e.g.,114) explicitly called by related process402.

In contrast,FIG. 5illustrates system500in which a memory release call is managed and does not require an explicit call from native code associated with the allocating process or another process related thereto. Thus, system500includes intercept component102illustrated to intercept memory allocation112explicitly or automatically called in connection with process106. However, rather than expecting a corresponding memory release call, such can be managed by, e.g., a garbage collection operation or algorithm or another managed process, denoted as garbage collection process208. In the case of managed operations such as garbage collection routines, intercept component102can subsequently intercept an associated memory release call (e.g., GC Start210, GC Finish212, . . . ) explicitly called by garbage collection process208.

Continuing the discussion ofFIG. 1, and with the foregoing in mind, additional detail can now be provided. In the context of the disclosed subject matter, it is understood that individual application programs run on a computer as a process (e.g., process106) administered by an operating system (e.g., OS108). Programs call (e.g., memory calls104) to the OS to allocate or free memory are provided as needed for the application to function as intended. However, due to a variety of factors, memory (e.g., memory110) use by a program (e.g., application202) can be problematic.

For example, when executing code from a particular process, there could be repeated allocations that are not freed, causing memory leaks, which can ultimately result in abnormal program termination, such as a crash. However, not all code that allocates memory, but later fails to free that memory can be considered a memory leak. In fact, many cases arise in which such is quite acceptable such as when allocated memory, along with the responsibility to later free that memory, is passed to some other process or code (e.g., related process402).

Another problematic issue with memory use by a program is that repeated non-leaking allocations can result in memory fragmentation. Thus, memory that is allocated and subsequently properly released can lead to a section of memory that is free that is not contiguous with other free sections of memory, resulting in successively smaller pieces of free memory. Eventually a memory request might be denied, resulting in failure, if the size of the memory request exceeds any available free section in the fragmented memory, even when the total amount of free memory is greater than the size of the memory request.

Yet another issue with memory use by a program relates to inefficient use. Inefficient memory use can cause performance degradation. For example, as more memory is used, more hard disk accesses can occur, and hard disk access is thousands of times slower than memory access. Such inefficient memory use can be caused by a variety of factors that commonly plague design and implementation of applications or programs.

For example, a particular program might allocate 10,000 bytes, but use only 100 bytes in connection with the much larger allocation. Similarly, a particular program might allocate 10,000 bytes, but use only a sparse pattern, such as 5 bytes out of every 100 bytes. Moreover, a particular program might, whether unintentionally or intentionally, might create many superfluous duplicate allocations or an allocation routine might double the size of the requested size intentionally based upon an assumption the data needed is Unicode, which takes two bytes per character, or based upon other design flaws or misconceptions. As still another example, code that lives in a module, such as a dynamic linked library (e.g., .DLL) file might be loaded into memory, but never accessed or otherwise used.

Furthermore, consider that with an extensible model for program development, dozens of internal and external teams can contribute code to the process, some of which can span many years, changes in constraints, approaches, goals, or policies, further complicating the memory picture. Hence, the code, and the execution of that code, is not often streamlined to consume smaller amounts of memory. Moreover, identifying these problems can be extremely difficult.

Difficulties in identifying these and related problems can arise for a variety of reasons. Generally speaking, memory use is essentially invisible to developers at many stages of the development process. One can readily see the total memory use at a particular instant. For example, any suitable memory performance monitor can show various totals, and one can observe whether or not these totals grow in size to infer a memory leak. However, a small leak can be extremely difficult to detect. Moreover, certain program behaviors might make it even more difficult to detect leaks.

For instance, certain programs can provide an “undo” feature. Thus, a user can provide numerous inputs, then select the undo feature many times. By relying upon memory storage, the program “remembers” which actions to undo and in precise order. Typically, such memory results in a normal memory use growth. As another example, certain programs can include a cache. Hence, a program can accumulate disk information in memory in order to speed up associated operations, which can also yield memory use growth.

Regardless, finding the exact code that causes a memory leak or other memory use growth can be quite complex for previous systems and users of those systems. In particular, a user examining memory use can be confronted with hundreds of millions of instructions executed per second with many thousands of memory allocations. Thus, the sheer volume of allocations can be difficult to track much less efficiently visualize or comprehend. Moreover, even upon successful identification of a particular 10 bytes of leaking memory, conventional systems often do not provide a ready means for understanding how to remedy the identified memory leak. Furthermore, it is often not even the responsibility of the allocating program to release or free the code. Therefore, even if conventional systems where able to identify the allocating line of code, there is no guarantee the responsibility to subsequently release that allocation resides with the allocating program, which further confounds users employing conventional systems.

Notwithstanding the many difficulties noted above with respect to native code, managed code presents even more complex issues with which to contend. For example, with managed code, there is no explicit release for an object. Rather, once no other object references the object in question, that object can be slated for garbage collection. Thus, in the case of managed code, the allocator is typically not responsible for releasing the allocated memory.

Moreover, with managed code, the Common Language Runtime (CLR) manages most memory for the application. Managed code such as Visual Basic (VB) or C Sharp (C#) does not explicitly free most memory uses. Rather, the CLR will periodically perform garbage collection. Generally speaking, garbage collection consists of a number of automatically performed operations. Such automatic operations can include, e.g., finding the “roots”, for example, those objects that are to be kept alive, such as thread or application domains. Such automatic operations can also include enumerating starting from those roots to find all objects in memory that are referenced by those roots and repeating for each newly found object, which can result in an object reference graph; moving objects that are in use closer together in memory, effectively coalescing free memory to reduce fragmentation and thus obliterating those objects that are “collected”; and updating object-to-object references, e.g., notifying an object that its referenced objects have moved. Thus, garbage collection for managed code frees unreferenced objects.

Furthermore, as noted previously, a program can allocate memory in many ways. For example, native code can allocate memory by employing VirtualAlloc for larger chunks, e.g., 64 kilobyte increments. For smaller chunks of memory, code can employ HeapCreate, HeapAlloc. Additionally or alternatively, native code can employ § malloc, or the operator “new” in certain native-oriented languages. For managed code, a program can allocate memory be way of creation of managed objects such as the operator “new” in managed-oriented languages. A program can also allocate memory via types (e.g., classes), appdomains, modules, mapped files and sections, threads, and so forth.

All these memory uses, whether native or managed, eventually call VirtualAlloc internally. However, except for the managed objects, each of these memory use techniques has a corresponding mechanism to free the memory with an explicit program call. For managed objects, the CLR will free objects that have no references, so the code only need remove references to memory that is to be freed by CLR.

With the foregoing in mind, consider a particular memory allocation of 10 bytes has been identified as leaking. In conventional systems, such would by itself be very difficult to discover. However, upon discovery, how does one describe the leak and/or a suitable remedy? One could assign fault to the line of code that called the code that ordered the memory allocation. However, that line of code might be just a helper line that was called from yet another helper, etc.

Thus, we see the importance of call stacks in getting to the source of the matter. Table I below provides an example call stack that is an actual allocation of 32 bytes for the 8-character string “Priority”. This string is stored in Unicode, which means 2*8=16 bytes, plus 2 null bytes. At the top of the stack provided by Table I, “Mine_RdAllocHeap”, represents a Heap Allocation call that was intercepted (e.g., by intercept component102). The next line, including, “ole32.dll!CRetailMalloc_Alloc” can be identified as the code that directs the actual allocation of memory, but we see this information does not necessarily tell us anything interesting. Instead, we have to scan the stack downward a few lines at a time and see that “Priority” is some sort of Provider Column related to a TaskList, which was created by a Service Provider from a VB Project creation, which itself stems from a Solution open, from an Open Solution Dialog invoked from a menu item or button.

Table I, above, represents a line-by-line output of an example call stack with managed code sections emphasized in bold font. The first line before the call stack describes the allocation. At the bottom is the actual 32 bytes displayed in three ways: as 4-byte integers, as bytes, and as characters.

In accordance with the subject matter described herein, various aspects or embodiments can provide one or more mechanisms (e.g., system100and related elements) to help identify various memory issues. Typically, in order to solve the issues that exist in conventional approaches, it is understood that a given solution can start with intercepting memory allocation calls. Any associated free call can also be intercepted. Such can include intercepting both managed and native allocation and free calls. The interception code can record the call stack of the caller as well as a few other bits of information such as the size, thread, and Sequence Number (1,2,3 . . . ) and can store this information in an associated Tag, all of which is substantially consistent with what has been described supra.

In order to underscore various objectives and constraints, it is noted that implementation can, e.g., (1) call or forward the underlying intercepted code in order for the program to behave correctly, ideally in a manner that minimizes resultant delay. (2) Operate extremely rapidly while utilizing as little memory as feasible and thus reduce potential program operation disruption. (3) Operate in a manner that is recursion-aware, since intercepted code can call other code or functions that can themselves be intercepted. (4) Operate in a manner that is thread-safe, given a particular application, program, or process can have scores of threads, each potentially including the capability of allocating memory.

Hence, for allocations, the disclosed subject matter can, generally, generate and store the associated tag containing the call stack and associated that tag with the actual memory allocation. For release or free operations, one feature includes matching an associated tag and freeing that tag along with the underlying memory. As a result, it is readily apparent that any currently allocated memory will typically have an associated tag.

Moreover, since part of the disclosed subject matter relates to call stacks, it is noted that recording of the call stack can require a fairly complex series of steps or acts, especially because various stack sections can be managed or native code, respectively, and procedures to walk each section type are quite different. While existing tools can be used to intercept memory calls, such tools can differ depending upon whether or not the case at hand is processing native code or managed code.

For example, to intercept native memory calls in a Windows-based environment, a tool known as Detours (see http colon slash slash research dot Microsoft dot com slash en dash us slash projects slash detours slash) can be employed. On the other hand, managed memory calls can be intercepted via ICorProfilerCallBack, which is a mechanism with which CLR notifies user code about certain events, including, e.g., AppDomain, Assembly, Class, Module Load Start/Finish, Objects Allocated (e.g., when a managed CLR object is created), GarbageCollectionStarted, GargageCollectionFinished, and so forth. For additional details relating to ICorProfilerCallBack, see http colon slash slash msdn dot Microsoft dot com slash en dash us slash library slash ms230818 dot aspx. It is understood that while two examples have been provided above for intercepting memory calls, other examples can exist. It is also understood that the disclosed subject matter is not necessarily limited to Windows-based environments, although such an environment serves as a ready example.

As noted above, the disclosed subject matter involves handling of the call stack-embedded tags that allow matching of a memory allocation with its associated memory free, and can accomplish such even though an allocated object has undergone garbage collection. In more detail, generally speaking, every application heap has a wrapper. This wrapper can contain the associated table of tags and these table and tags can be stored in a private heap (e.g., private heap120) that does not have the wrapper. When a heap allocation is intercepted, the tag and its included call stack can be generated and stored in the private heap.

Likewise, when a memory release or free occurs for the heap, the intercepted free finds and frees the associated tag. Notice, such is straightforward for tracking heap allocations. However, for all other types of allocations, such as managed objects, VirtualAllocs, mapped files, and so on another single private heap can be created with the wrapper, which is referred to herein as the MemSpect heap. Thus, interception of the latter type of calls merely puts some information about the call (e.g., Managed Class ID, VirtualAlloc type, Mapped Filename) into the _MemSpect heap, which can be a different set of information recorded to a particular tag that is included in the first described private heap. Because the _MemSpect heap is a wrapped heap, the call stack can be automatically calculated and stored as a normally intercepted heap allocation.

For managed objects, e.g., GC Start and GC Finish, those objects can be intercepted and the tags for the managed objects that were collected and moved can be processed. Each managed object can have an ID that represents the associated address in memory. However, note that this address can change as objects are moved around, which can occur during conventional garbage collection operations. Thus, garbage collection deals with ranges of objects that are defined as a starting address and a length. Put another way, managed object allocations can be intercepted. The garbage collection operation can also be intercepted and interpreted to determine if the object has been “freed” or collected.

Hence, ICorProfilerCallBack2:: GarbageCollectionStarted can indicate the number and kind of garbage collection that is starting. In addition, it is understood the CLR maintains several “Generations” of objects. For example, an object typically starts at Gen0. If that objects survives long enough, the object is promoted to Gen1, and so on. Generally, the higher the generation count, the less often an underlying object is collected. Moreover, some objects are considered too large for moving, so such large objects exist in a higher generation. At this point, ICorProfilerInfo2::GetGenerationBounds can be called to find the ranges of object IDs that will undergo collection in each generation for this particular invocation of garbage collection.

In addition, ICorProfilerCallBack::MovedReferences can be leveraged to indicate the multiple ranges of object IDs that have moved. These object IDs can be collected and saved into RangeCollection for processing in GCFinished. Furthermore, ICorProfilerCallBack2::SurvivingReferences can indicate the multiple ranges of object IDs that have survived garbage collection. These surviving object IDs can also be collected and saved into RangeCollection for processing in GCFinished. Finally, ICorProfilerCallBack2::GarbageCollectionFinished is where the tracking for the objects can be resolved, for which example logical code is provided below:

//Start CodeFor each GenerationIf this Gen is being collectedFor each generation boundIf the generation bound is the same as thegen being collectedDoRangeWalkEnd IfEnd For // each gen boundEnd ifEnd for// each generationDoRangeWalk:// we'll do a parallel walk of RangeCollection and _MemSpectobjects// must be very fast and careful walking ranges while inserting ordeleting into themInitialize the MovedTagInfoListCalculate the lowest and highest object in the generation boundsCalculate the lowest and highest in the _MemSpect Heap basedon the generation boundsRangeCurrent = RangeCollection(lowest in generation)if (RangeCurrent not at end)For each object between the lowest and highest in the _MemSpect Heapwhile the object is beyond RangeCurrentRangeCurrent = next in RangeCollectionIf RangeCurrent at endExit ForEnd ifEnd whileIf the object is within RangeCurrentProcessObjectEnd ifEnd ForProcessMovedObjectListEnd ifProcessObject:If the Object SurvivedIncrement the associated object's Survival Counter andgenerationElse if Moved// now we must patch the object in the _MemSpect heap:// essentially we create a new Tag with the new object ID,copy the old call stack to it// then add info about the move to a MovedTagInfoListFind the object's original TagAllocate memory in the private heap and copythe original tag including call stack we're about to deleteCreate a new TagInfo based on the original (same as Tagwithout the call stack)Increment the New TagInfo's Moved CounterRecord the generation number in the New TagInfo (couldhave moved generation)Save info about move into a MovedTagInfoListFree the associated tag in the _MemSpect heapElse// didn't move or survive: Must have been collected.Find and Increment the associated class's Collected CounterFree the associated tag in the _MemSpect heapEnd ifProcessMovedObjectList:// avoid inserting while the ranges are being walkedFor each tag in MovedTagInfoListAdd the TagInfo into the _MemSpect heap // this uses the currentcall stack, which needs to be patchedFind the callstack of the Tag just addedReplace with the call stack in the MovedTagInfoListEnd For//End Code

Referring now toFIG. 6, system600that can present various views of data tracked by the disclosed subject matter is depicted. Generally, system600can include all or a portion of system100substantially detailed supra. In addition, system600can further include interface component that can be configured to present data included in tag118. Such data can be presented by way of a user interface, example features of which are illustrated by example user interface features604. It is understood that interface component602and/or one or more elements included in system100can be operatively or communicatively coupled to memory110, including private heap120.

In one or more aspect, interface component602can be further configured to present information derived from data included in tag118. Accordingly, views or interpretations provided by interface component602can be based upon express data included in one or more tag118or can be derived from such data. In one or more aspect, interface component602can be further configured to contemporaneously present information associated with multiple call stacks associated with multiple tags (e.g., tag118).

Furthermore, in one or more aspect, interface component602can be further configured to present a file name associated with the memory allocation instruction (e.g., memory allocation call112). Likewise, in one or more aspect, interface component602can be further configured to present a file line number associated with the memory allocation instruction. In addition, in one or more aspect, interface component602can be further configured to present a module name associated with the memory allocation instruction. Similarly, in one or more aspect, interface component602can be further configured to present a class name associated with the memory allocation instruction. Furthermore, in one or more aspect, interface component602can be further configured to present a method name associated with the memory allocation instruction.

Additionally or alternatively, in one or more aspect, interface component602can be further configured to present a list of the at least one process106ordered by the number of associated memory allocations. Moreover, in one or more aspect, interface component602can be further configured to present a list of the at least one process106ordered by the total memory size of associated memory allocations.

Turning now toFIG. 7, system700that can facilitate memory tracking in a managed memory environment is illustrated. In generally, system700can include all or portions of system100as described herein. Hence, system100can intercept memory allocation call112that is explicitly called by process106. When assuming a different process is responsible for releasing that allocated memory, such as garbage collection process208. Memory released in this manner does not require explicit call from native code. Moreover, such memory can be moved, which can change addresses or pointers to those portions of memory.

Accordingly, system700can further include update component702that can be configured to update tag118in response to a change to a memory allocation reference provided by garbage collection process208. It is understood that example implementations for such are described above, yet such examples need not be limiting in nature.

FIGS. 8-10illustrate various methodologies in accordance with the disclosed subject matter. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and noted that the disclosed subject matter is not limited by the order of acts, as some acts may occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology can alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the disclosed subject matter. Additionally, it is to be further noted that the methodologies disclosed hereinafter and throughout this disclosure are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computers.

Referring now toFIG. 8, exemplary method800for tracking computer-based memory provisioning is depicted. Generally, at reference numeral802, a processor can be employed for intercepting a memory transaction from at least one process that allocates computer memory or that frees computer memory, wherein the memory transaction is a memory allocation command or a memory free command.

Moreover, at reference numeral804, a tag can be created in response to intercepting the memory allocation command of reference numeral802. Upon creation of the tag, various information can be included therein. For example, at reference numeral806, the tag a call stack associated with the at least one process, an allocation size of the memory allocation, a thread identification, and a tag sequence number can be included in the tag. It is noted that other information can be included in the tag, and that the particular type or character of information included in the tag can depend upon the type of memory allocation and/or memory release that is expected, e.g., native versus managed.

Regardless, at reference numeral808, the tag can be stored to a private memory heap. This private memory heap can be specifically allocated for use by the disclosed subject matter, as detailed herein, and can have a wrapper or exist without a wrapper, e.g., based upon the type of memory allocation and/or memory release that is expected. Moreover, more than one private memory heap can exist, such as a first private heap for certain types of memory allocation/release and a second private heap for other types of memory allocation/release. However, regardless of the type of memory allocation/release, at reference numeral810, the tag can be deleted in response to a matching memory free (or release) command.

Turning now toFIG. 9, exemplary method900for providing additional features or aspects in connection with tracking computer-based memory provisioning is illustrated. For example, at reference numeral902, memory can be allocated according to the memory allocation command. Thus, even though the memory allocation command is intercepted, that command can be forwarded to its original destination in order to ensure the disclosed tracking features do not interfere with otherwise expected operation of a particular application or process.

Similarly, at reference numeral904, memory can be released or freed according to the memory free command. Hence, as with allocation of the memory, subsequent freeing of that memory can be effectuated in a transparent manner that does not significantly affect normal operation of the application(s) or process(es) that is/are monitored, whether such is effectuated by forwarding the original memory free command or by some other means.

At reference numeral906, the memory allocation command and the memory free command can be received as explicit instructions from the at least one process. Alternatively, at reference numeral908, the memory free command and/or the memory allocation command can be received in connection with a system-managed garbage collection routine. In the latter case discussed with regard to reference numeral908, then at reference numeral910, the tag can be updated in response to a change in a memory allocation reference provided by the system-managed garbage collection routine.

With reference now toFIG. 10, exemplary method1000for presenting data in connection with tracking computer-based memory provisioning is provided. In general, at reference numeral1002, data included in the tag or information derived from data included in the tag can be presented, for example by way of a user interface and according to one or several different views or pivots. At reference numeral1004, information associated with multiple call stacks associated with multiple tags can be presented concurrently. It is to be underscored that conventional systems typically only display, at most, a single call stack, which has limited utility. However, the disclosed subject matter can provide views or other presentations that involve multiple call stacks.

Next to be described, at reference numeral906, at least one of a file name associated with the memory allocation command, a file line number associated with the memory allocation command, a module name associated with the memory allocation command, a class name associated with the memory allocation command, or a method name associated with the memory allocation command can be presented. Furthermore, at reference numeral908, a list of the at least one process ordered by one of: a number of associated memory allocations or a total memory size of associated memory allocations can be presented.

Exemplary Networked and Distributed Environments

One of ordinary skill in the art can appreciate that the various embodiments of dynamic composition described herein can be implemented in connection with any computer or other client or server device, which can be deployed as part of a computer network or in a distributed computing environment, and can be connected to any kind of data store where media may be found. In this regard, the various embodiments described herein can be implemented in any computer system or environment having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units. This includes, but is not limited to, an environment with server computers and client computers deployed in a network environment or a distributed computing environment, having remote or local storage.

Distributed computing provides sharing of computer resources and services by communicative exchange among computing devices and systems. These resources and services include the exchange of information, cache storage and disk storage for objects, such as files. These resources and services also include the sharing of processing power across multiple processing units for load balancing, expansion of resources, specialization of processing, and the like. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may participate in the smooth streaming mechanisms as described for various embodiments of the subject disclosure.

FIG. 11provides a schematic diagram of an exemplary networked or distributed computing environment. The distributed computing environment comprises computing objects1110,1112, etc. and computing objects or devices1120,1122,1124,1126,1128, etc., which may include programs, methods, data stores, programmable logic, etc., as represented by applications1130,1132,1134,1136,1138. It can be noted that computing objects1110,1112, etc. and computing objects or devices1120,1122,1124,1126,1128, etc. may comprise different devices, such as PDAs, audio/video devices, mobile phones, MP3 players, personal computers, laptops, etc.

Each computing object1110,1112, etc. and computing objects or devices1120,1122,1124,1126,1128, etc. can communicate with one or more other computing objects1110,1112, etc. and computing objects or devices1120,1122,1124,1126,1128, etc. by way of the communications network1140, either directly or indirectly. Even though illustrated as a single element inFIG. 11, network1140may comprise other computing objects and computing devices that provide services to the system ofFIG. 11, and/or may represent multiple interconnected networks, which are not shown. Each computing object1110,1112, etc. or computing objects or devices1120,1122,1124,1126,1128, etc. can also contain an application, such as applications1130,1132,1134,1136,1138, that might make use of an API, or other object, software, firmware and/or hardware, suitable for communication with or implementation of the smooth streaming provided in accordance with various embodiments of the subject disclosure.

Thus, a host of network topologies and network infrastructures, such as client/server, peer-to-peer, or hybrid architectures, can be utilized. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. A client can be a process, i.e., roughly a set of instructions or tasks, that requests a service provided by another program or process. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself.

In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer, e.g., a server. In the illustration ofFIG. 11, as a non-limiting example, computing objects or devices1120,1122,1124,1126,1128, etc. can be thought of as clients and computing objects1110,1112, etc. can be thought of as servers where computing objects1110,1112, etc. provide data services, such as receiving data from client computing objects or devices1120,1122,1124,1126,1128, etc., storing of data, processing of data, transmitting data to client computing objects or devices1120,1122,1124,1126,1128, etc., although any computer can be considered a client, a server, or both, depending on the circumstances. Any of these computing devices may be processing data, or requesting transaction services or tasks that may implicate the techniques for dynamic composition systems as described herein for one or more embodiments.

In a network environment in which the communications network/bus1140is the Internet, for example, the computing objects1110,1112, etc. can be Web servers with which the client computing objects or devices1120,1122,1124,1126,1128, etc. communicate via any of a number of known protocols, such as the hypertext transfer protocol (HTTP). Servers1110,1112, etc. may also serve as client computing objects or devices1120,1122,1124,1126,1128, etc., as may be characteristic of a distributed computing environment.

Exemplary Computing Device

As mentioned, advantageously, the techniques described herein can be applied to any device where it is desirable to perform dynamic composition. It is to be understood, therefore, that handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the various embodiments, i.e., anywhere that a device may wish to read or write transactions from or to a data store. Accordingly, the below general purpose remote computer described below inFIG. 2is but one example of a computing device. Additionally, a database server can include one or more aspects of the below general purpose computer, such as a media server or consuming device for the dynamic composition techniques, or other media management server components.

FIG. 12thus illustrates an example of a suitable computing system environment1200in which one or aspects of the embodiments described herein can be implemented, although as made clear above, the computing system environment1200is only one example of a suitable computing environment and is not intended to suggest any limitation as to scope of use or functionality. Neither is the computing environment1200be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment1200.

With reference toFIG. 12, an exemplary remote device for implementing one or more embodiments includes a general purpose computing device in the form of a computer1210. Components of computer1210may include, but are not limited to, a processing unit1220, a system memory1230, and a system bus1222that couples various system components including the system memory to the processing unit1220.

Computer1210typically includes a variety of computer readable media and can be any available media that can be accessed by computer1210. The system memory1230may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). By way of example, and not limitation, memory1230may also include an operating system, application programs, other program modules, and program data.

A user can enter commands and information into the computer1210through input devices1240. A monitor or other type of display device is also connected to the system bus1222via an interface, such as output interface1250. In addition to a monitor, computers can also include other peripheral output devices such as speakers and a printer, which may be connected through output interface1250.

The computer1210may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote computer1270. The remote computer1270may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer1210. The logical connections depicted inFIG. 12include a network1272, such local area network (LAN) or a wide area network (WAN), but may also include other networks/buses. Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while exemplary embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system in which it is desirable to publish or consume media in a flexible way.

Also, there are multiple ways to implement the same or similar functionality, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software object, etc. which enables applications and services to take advantage of the dynamic composition techniques. Thus, embodiments herein are contemplated from the standpoint of an API (or other software object), as well as from a software or hardware object that implements one or more aspects of the smooth streaming described herein. Thus, various embodiments described herein can have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.