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

Reply via email to