> I see, so the hypothesis is that 100% of the fragmentation is coming from > VirtualAlloc/MapViewOfFile, not from allocations in general?
jemalloc does not make 4kb allocations, I think ever. So yes. On Tue, Apr 9, 2013 at 9:23 AM, Kevin Gadd <kevin.g...@gmail.com> wrote: > 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 >>> >>> 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
