The Memory Profile viewer displays a memory usage report for the application of interest.
To view a Memory Profile report:
Select the Memory Profile tab.
Select the menu item Memory Profile->Hide/Show Data->Hide/Show Referenced Objects.
The Report Window on the left-hand side of the UI displays a list containing each memory snapshot and the time at which they occurred; as you may recall, the TDP Configuration was updated so that a snapshot would occur immediately following each garbage collection. The Memory Profile tab contains a sortable table (i.e. sortable via a left-click on a column header) with the following information:
Method - Each method that, when called, resulted in the instantiation of an object. A left-click on any method names brings you to the portion of source code in which this method has been defined.
Referenced Object Class - If any method in the first column continues to reference an object at the time of the snapshot, the object is listed in this column. Of course, many objects are allocated and deallocated before a snapshot - in this case, the object allocation is recorded but the object reference is not.
Allocated Objects- Total number of objects created by a method throughout execution of the monitored application.
Allocated Bytes - Total number of bytes associated with the objects created by a method.
L + D Allocated Objects - Total number of objects created by the "local" method and by any descendant methods - that is, by any method that was called as a result of the specified method.
L + D Allocated Bytes - Total number of bytes associated with the objects created by the "local" method and by any descendant methods.
Note how this table is referred to as a "snapshot" at the very top. A user is able to predefine moments at which a memory snapshot should take place - this is done via Configuration Settings. At each snapshot, the JVMPI interface of the targeted JVM is queried and information about each individual method is acquired. For example, if you have designed a particular, cyclic portion of your code to deallocate all unnecessary memory prior to each iteration, set a snapshot to occur each time the cycle is entered. The Memory Profile report contains diff functionality - you will explore this capability later - that can tell you if additional memory remains allocated when the cycle is reentered.
Notice how easily this information has been acquired; no work was required on your part. A real advantage is that memory profiling can now be part of your regression test suite. Traditionally, if embedded developers looked for careless memory allocation/deallocation at all, it was done while using a debugger - a process that does not lend itself to automation and thus repeatability. The memory profiling feature lets you automate memory leak detection.
And again, the identical functionality can be used on either your host platform or on your embedded target.