> On 15 Aug 2011, at 12:03, Ludo Brands wrote: > > > 100.00% (288,964,608B) (page allocation syscalls) mmap/mremap/brk, > > --alloc-fns, etc. > > ->37.20% (107,483,136B) 0x80C7DD3: > > ->SYSTEM_FPSYSCALL$LONGINT$LONGINT$$LONGINT > > (in /home/ludo/lazarus/lazarus) > > | ->37.20% (107,483,136B) 0x80C86DF: > > > SYSTEM_FPMMAP$POINTER$LONGWORD$LONGINT$LONGINT$LONGINT$INT64$$POINTER > > (in > > /home/ludo/lazarus/lazarus) > > | ->37.20% (107,483,136B) 0x80DE2EE: > > | SYSTEM_SYSOSALLOC$LONGWORD$$POINTER > > (in /home/ludo/lazarus/lazarus) > > Note that if you want to see what part of the memory > allocation is due to the program and what part due to > internal fragmentation in the memory manager, you should > compile with -gv (or add the "cmem" unit as the first unit to > the uses-clause of Lazarus). Then the program will use libc's > malloc/free/realloc/..., and Valgrind will be able to track > every allocation/deallocation individually. > >
Yes, that is what I'm doing lately. This is an older trace I took to illustrate to Max how the memory allocated by "custom" memory allocators such as "SYSTEM_ALLOC_OSCHUNK" are split up by the massif tool. Ludo _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
