I see, so the hypothesis is that 100% of the fragmentation is coming from VirtualAlloc/MapViewOfFile, not from allocations in general? I believe the kernel instrumentation tools could give you data on this but it would probably require modifications to the profiler tool, so maybe it can't be used to answer questions about 'who allocated this'.
It does appear that MS offers a utility for this, though, called LeakDiag: http://blogs.jetbrains.com/yole/archives/000034.html It appears to instrument VirtualAlloc and record tracebacks. Maybe worth a look. On Tue, Apr 9, 2013 at 6:07 AM, Benjamin Smedberg <benja...@smedbergs.us>wrote: > On 4/9/13 7:12 AM, Kevin Gadd wrote: > >> This is one of the problems Heap Profiler was written to solve: >> >> https://github.com/kevingadd/**HeapProfiler<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). >> > As far as I understand it, this tool profiles heap allocations like > "malloc". I am not concerned with those allocations, but only with page > allocations. Can this tool intercept calls to VirtualAlloc and especially > MapViewOfFile so that we can see the stack at the point the large memory > mappings are created? > > Note that although it's interesting that we're fragmenting the page > because of the 4k/64k behavior, I am much less concerned with that behavior > than I am with the leaked memory mappings. > > --BDS > > -- -kg _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
