Confirmed users
1,345
edits
Platform/Memory Reporting: Difference between revisions
Jump to navigation
Jump to search
→A Simple Example
Nnethercote (talk | contribs) |
Nnethercote (talk | contribs) |
||
| Line 57: | Line 57: | ||
size_t MyString::SizeOfExcludingThis(nsMallocSizeOfFun aMallocSizeOf) const { | size_t MyString::SizeOfExcludingThis(nsMallocSizeOfFun aMallocSizeOf) const { | ||
return aMallocSizeOf(mBuffer | return aMallocSizeOf(mBuffer); | ||
} | } | ||
size_t MyString::SizeOfIncludingThis(nsMallocSizeOfFun aMallocSizeOf) const { | size_t MyString::SizeOfIncludingThis(nsMallocSizeOfFun aMallocSizeOf) const { | ||
return aMallocSizeOf(this | return aMallocSizeOf(this) + SizeOfExcludingThis(aMallocSizeOf); | ||
} | } | ||
| Line 68: | Line 67: | ||
typedef size_t(*nsMallocSizeOfFun)(const void *p, size_t computedSize); | typedef size_t(*nsMallocSizeOfFun)(const void *p, size_t computedSize); | ||
(The JS engine has a synonym called <tt>JSMallocSizeOfFun</tt>.) Functions with this signature measure the size of <tt>p</tt> by asking the heap allocator how big it is (via <tt>moz_malloc_usable_size</tt> | (The JS engine has a synonym called <tt>JSMallocSizeOfFun</tt>.) Functions with this signature measure the size of <tt>p</tt> by asking the heap allocator how big it is (via <tt>moz_malloc_usable_size</tt>). | ||
All this is | All this is probably not what you'd expect, but the above functions have the following crucial features. | ||
* They let you measure the <tt>MyString</tt> object itself or not as necessary. This is important because sometimes an object might be embedded in another object that is measured separately. And the names make it clear exactly what is being measured. | * They let you measure the <tt>MyString</tt> object itself or not as necessary. This is important because sometimes an object might be embedded in another object that is measured separately. And the names make it clear exactly what is being measured. | ||
* On platforms that allow it, they count the actual memory in use, including slop bytes caused by the heap allocator rounding up request sizes (a.k.a. internal fragmentation). If slop bytes aren't measured they'll end up in about:memory's <tt>heap-unclassified</tt> entry, which is bad. | * On platforms that allow it, they count the actual memory in use, including "slop" bytes caused by the heap allocator rounding up request sizes (a.k.a. internal fragmentation). If slop bytes aren't measured they'll end up in about:memory's <tt>heap-unclassified</tt> entry, which is bad. | ||
* | * The size is not computed analytically. For example, <tt>sizeof</tt> doesn't appear anywhere. This is a good thing, because computing sizes analytically doesn't count slop, and it is much more error-prone than using <tt>moz_malloc_usable_size</tt>. | ||
* They are flexible and integrate well with DMD. The <tt>aMallocSizeOf</tt> parameter allows <tt>nsMallocSizeOfFun</tt> functions with DMD-specific hooks to be passed in when they are used by memory reporters, but functions without such hooks (such as <tt>moz_malloc_size_of</tt>) can also be passed in when they are used in other circumstances. | * They are flexible and integrate well with DMD. The <tt>aMallocSizeOf</tt> parameter allows <tt>nsMallocSizeOfFun</tt> functions with DMD-specific hooks to be passed in when they are used by memory reporters, but functions without such hooks (such as <tt>moz_malloc_size_of</tt>) can also be passed in when they are used in other circumstances. | ||