You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(13) |
2
(15) |
|
3
(16) |
4
(42) |
5
(9) |
6
(20) |
7
(22) |
8
(24) |
9
(12) |
|
10
(24) |
11
(11) |
12
(2) |
13
(13) |
14
(8) |
15
|
16
(16) |
|
17
(24) |
18
(36) |
19
(100) |
20
(94) |
21
(50) |
22
(39) |
23
(10) |
|
24
(14) |
25
(19) |
26
(2) |
27
(6) |
28
(17) |
29
(9) |
30
(8) |
|
31
(21) |
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2009-05-14 22:34:05
|
I am working on callgrind to add the capture of alloc/free information events.
I have now something which starts to work (at least on small examples).
This allows then to use the callgrind/kcachegrind to examine e.g. graphically
the heap memory usage. In other words, this is similar to massif, but integrated
within callgrind and its graphical tool. The result on small examples
looks nice in kcachegrind.
The events I am currently capturing is:
allocSize (increased by N when N bytes are allocated)
in the callgraph, associated to the callstack that did the alloc
freeSize (increased by N when N bytes are freed).
in the callgraph, associated to the callstack that did the free
(this allows to see who allocates and/or who frees a lot).
To this, I would like to add a "releasedSize" event.
The releasedSize will be increased similarly to freeSize but the idea is to associate
this cost to the same callstack that allocated the memory being freed.
With this "releasedSize", the current memory usage of the heap can be examined in kcachegrind
by using the cost "allocSize - releasedSize"
This will allow to see which stack trace "keeps" a lot of memory.
I have tried a naive (and incorrect) approach to implement releasedSize:
At allocation time, I am saving somewhere the pointer and the bbcc used at allocation.
When the pointer is released, I am retrieving the corresponding bbcc and adding the size
of the block freed to the releasedSize cost of this bbcc.
At the end of the run, I see that the total releasedSize is incremented (but twice the
nr of bytes freed). Moreover, nothing appears in the "self" or "inclusive" columns
for this event.
I guess that I need to do something more complex, like:
* saving a full chain of bbcc (or something like that) at allocation time
* and then propagate the releasedSize on this chain of bbcc
Or maybe save the stack trace (execontext) and "simulate" a call to
propagate the releasedSize ?
I have read here and there callgrind code, but it is not clear to me how to attack this.
Any advice/pointers about how to go/ what to read in detail/ ... ?
Thanks for any help
|
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 08:08:51
|
On Thu, May 14, 2009 at 6:08 PM, Julian Seward <js...@ac...> wrote: > >> Actually, one very important question: when do you imagine this would >> be merged with the trunk relative to the Darwin merge? I'd prefer the >> Darwin merge to happen earlier because it's big and complex. > > Probably after Darwin, on the basis that Darwin is much more complex > and difficult to merge, and also that it is pretty close to being merged. > > Do you have a tentative timescale on which to do the Darwin merge? If all goes well, maybe by the end of next week? N |
|
From: Julian S. <js...@ac...> - 2009-05-14 08:05:23
|
> Actually, one very important question: when do you imagine this would > be merged with the trunk relative to the Darwin merge? I'd prefer the > Darwin merge to happen earlier because it's big and complex. Probably after Darwin, on the basis that Darwin is much more complex and difficult to merge, and also that it is pretty close to being merged. Do you have a tentative timescale on which to do the Darwin merge? J |
|
From: Julian S. <js...@ac...> - 2009-05-14 07:43:22
|
On Thursday 14 May 2009, Nicholas Nethercote wrote: > On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: > > I've been mulling over some changes in how V emits output. It > > seems to me the output systems are in need of an overhaul, to > > fix various problems. > > It all sounds good to me, with one nitpick: > > (b) tool-stats printing to be moved to a different flag, > > -s | --tool-stats > > --tool-stats is a bad name if it covers core stats as well. Just > --stats=yes would be fine. Yup. J |
|
From: Tom H. <th...@cy...> - 2009-05-14 02:44:31
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-05-14 03:05:07 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 480 tests, 0 stderr failures, 0 stdout failures, 0 post failures == |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 02:35:19
|
On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: > > I've been mulling over some changes in how V emits output. It > seems to me the output systems are in need of an overhaul, to > fix various problems. It all sounds good to me, with one nitpick: > (b) tool-stats printing to be moved to a different flag, > -s | --tool-stats --tool-stats is a bad name if it covers core stats as well. Just --stats=yes would be fine. N |
|
From: Tom H. <th...@cy...> - 2009-05-14 02:27:40
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-05-14 03:10:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 486 tests, 0 stderr failures, 1 stdout failure, 0 post failures == none/tests/linux/mremap2 (stdout) |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-14 02:25:19
|
On Thu, May 14, 2009 at 11:31 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, May 13, 2009 at 9:16 PM, Julian Seward <js...@ac...> wrote: >> >> I've been mulling over some changes in how V emits output. It >> seems to me the output systems are in need of an overhaul, to >> fix various problems. > > It all sounds good to me Actually, one very important question: when do you imagine this would be merged with the trunk relative to the Darwin merge? I'd prefer the Darwin merge to happen earlier because it's big and complex. In comparison, the messaging merge would be big but fairly simple(?) Nick |