Lines Matching full:blocks
23 <para>It tracks the allocated blocks, and inspects every memory access
30 blocks)</para></listitem>
33 blocks)</para></listitem>
41 <listitem><para>for allocation points which always allocate blocks
52 <listitem><para>potential process-lifetime leaks: blocks allocated
60 short lived blocks</para></listitem>
62 <listitem><para>useless or underused allocations: blocks which are
66 <listitem><para>blocks with inefficient layout -- areas never
101 max-live: 63,490 in 984 blocks
102 tot-alloc: 1,904,700 in 29,520 blocks (avg size 64.52)
112 point) allocated 29,520 blocks in total, containing 1,904,700 bytes in
113 total. By looking at the max-live data, we see that not many blocks
115 allocated bytes in 984 blocks. This tells us that the program is
116 steadily freeing such blocks as it runs, rather than hanging on to all
119 <para>The deaths entry tells us that 29,520 blocks allocated by this stack
121 also the number of blocks allocated in total, that tells us that
122 all allocated blocks were freed by the end of the program.</para>
144 max-live: 32,512 in 254 blocks
145 tot-alloc: 32,512 in 254 blocks (avg size 128.00)
156 are identical. The only way that can happen is if these blocks are
163 all 254 blocks were allocated in the first half of the run, held onto
176 max-live: 49,398 in 808 blocks
177 tot-alloc: 1,481,940 in 24,240 blocks (avg size 61.13)
186 <para>The acc-ratios field tells us that each byte in the blocks
188 deallocated. Given that the blocks have an average age at death of
190 million instructions. So from that standpoint the blocks aren't
195 blocks are never written, at least 9% on average. To completely
201 <para>Well, at least all the blocks are freed (24,240 allocations,
204 <para>If all the blocks had been the same size, DHAT would also show
206 unused areas are. However, that isn't the case: the blocks have
215 max-live: 180,224 in 22 blocks
216 tot-alloc: 180,224 in 22 blocks (avg size 8192.00)
217 deaths: none (none of these blocks were freed)
226 this point is allocating blocks which are never used, neither read nor
232 DHAT can tell us, that Memcheck can't, is that not only are the blocks
237 <para>Here's one where blocks are allocated, written to,
242 max-live: 54 in 3 blocks
243 tot-alloc: 1,620 in 90 blocks (avg size 18.00)
252 <para>In the previous two examples, it is easy to see blocks that are
271 <para>For allocation points that always allocate blocks of the same
276 max-live: 317,408 in 5,668 blocks
277 tot-alloc: 317,408 in 5,668 blocks (avg size 56.00)
297 platform. Here, we have aggregated access statistics for 5668 blocks,
377 <para><varname>max-blocks-live </varname> maximum live blocks</para>
378 <para><varname>tot-blocks-allocd </varname> blocks allocated in total (turnover)</para>
382 by the highest number of live blocks, or the highest total block
384 For example, sorting by maximum live blocks tends to show up allocation
