This is one of the problems Heap Profiler was written to solve: https://github.com/kevingadd/HeapProfiler
It enables stack trace captures at allocation time, so at any given point in the capture you can open the heap and see who allocated a given block of memory. It can also display a fragmentation summary. It would probably be trivial to extend it to do a fragmentation analysis and generate a summary of who's causing the most fragmentation (by module or function, most likely). See http://www.luminance.org/blog/code/2011/06/03/diving-into-memory-usage-with-heap-profilerand http://www.luminance.org/blog/code/2011/08/01/a-journey-into-linker-hell-and-a-mistakefor some examples of usage. On Mon, Apr 8, 2013 at 11:39 PM, Mike Hommey <m...@glandium.org> wrote: > On Mon, Apr 08, 2013 at 08:09:08PM -0400, Justin Lebar wrote: > > > AIUI, on Windows the smallest block you can ask for with VirtualAlloc > > > is 4 KiB. However, no more than one VirtualAlloc block can exist per > > > 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the > > > remaining 60 KiB of address space in the 64 KiB chunk. > > > > Awesome memory, Nick. > > > > MSDN seems to confirm this. > > > > "The second parameter [to VirtualAlloc] indicates the range of > > addresses the function should allocate. This value can be anywhere > > from one page to 2 GB in size, but VirtualAlloc is actually > > constrained to a smaller range than that. The minimum size that can be > > reserved is 64K, and the maximum that can be reserved is the largest > > contiguous range of free addresses in the process. Requesting one page > > of reserved addresses results in a 64K address range." > > > > http://msdn.microsoft.com/en-us/library/ms810627.aspx > > > > We have the ability to intercept VirtualAlloc calls on Windows, so > > assuming that works for these particular VirtualAlloc calls (it > > should?) perhaps we can take backtraces and write them to a file. > > We're already intercepting VirtualAlloc in > xpcom/base/AvailableMemoryTracker.cpp > > Mike > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- -kg _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform