Lines Matching full:blocks
44 <p>It tracks the allocated blocks, and inspects every memory access
50 blocks)</p></li>
52 blocks)</p></li>
57 <li class="listitem"><p>for allocation points which always allocate blocks
65 <li class="listitem"><p>potential process-lifetime leaks: blocks allocated
71 short lived blocks</p></li>
72 <li class="listitem"><p>useless or underused allocations: blocks which are
75 <li class="listitem"><p>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)
111 point) allocated 29,520 blocks in total, containing 1,904,700 bytes in
112 total. By looking at the max-live data, we see that not many blocks
114 allocated bytes in 984 blocks. This tells us that the program is
115 steadily freeing such blocks as it runs, rather than hanging on to all
117 <p>The deaths entry tells us that 29,520 blocks allocated by this stack
119 also the number of blocks allocated in total, that tells us that
120 all allocated blocks were freed by the end of the program.</p>
139 max-live: 32,512 in 254 blocks
140 tot-alloc: 32,512 in 254 blocks (avg size 128.00)
150 are identical. The only way that can happen is if these blocks are
156 all 254 blocks were allocated in the first half of the run, held onto
165 max-live: 49,398 in 808 blocks
166 tot-alloc: 1,481,940 in 24,240 blocks (avg size 61.13)
174 <p>The acc-ratios field tells us that each byte in the blocks
176 deallocated. Given that the blocks have an average age at death of
178 million instructions. So from that standpoint the blocks aren't
182 blocks are never written, at least 9% on average. To completely
187 <p>Well, at least all the blocks are freed (24,240 allocations,
189 <p>If all the blocks had been the same size, DHAT would also show
191 unused areas are. However, that isn't the case: the blocks have
198 max-live: 180,224 in 22 blocks
199 tot-alloc: 180,224 in 22 blocks (avg size 8192.00)
200 deaths: none (none of these blocks were freed)
208 this point is allocating blocks which are never used, neither read nor
213 DHAT can tell us, that Memcheck can't, is that not only are the blocks
217 <p>Here's one where blocks are allocated, written to,
221 max-live: 54 in 3 blocks
222 tot-alloc: 1,620 in 90 blocks (avg size 18.00)
230 <p>In the previous two examples, it is easy to see blocks that are
245 <p>For allocation points that always allocate blocks of the same
249 max-live: 317,408 in 5,668 blocks
250 tot-alloc: 317,408 in 5,668 blocks (avg size 56.00)
269 platform. Here, we have aggregated access statistics for 5668 blocks,
331 <p><code class="varname">max-blocks-live </code> maximum live blocks</p>
332 <p><code class="varname">tot-blocks-allocd </code> blocks allocated in total (turnover)</p>
336 by the highest number of live blocks, or the highest total block
338 For example, sorting by maximum live blocks tends to show up allocation
