Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Friday, April 21, 2006
 Improving our memory debugging infrastructure

Federico writes about two small fixes we need to improve the memory debugging output of valgrind.

I've been working on a different approach: Instead of asking glib to be gc-friendly and to use malloc instead of g_slice implementation, I wrote patches for glib to hint valgrind directly. What it means is that glib will continue to use g_slice's complex implementation, and no gc-friendly cleanups, but it will give valgrind hints when a slice of memory is "freed" either using g_slice_free or for example g_array_resize...

With this patch you neither need to set G_DEBUG=gc-friendly, nor G_SLICE=malloc. glib simply picks it up when it's running under valgrind (or on top of ;). The patch also implements a global flag called g_mem_in_checker, that will be set to TRUE when running under valgrind (or other memory checkers in the future). ORBit then can check both this flag and g_mem_gc_friendly to initialize its buffers before writing them out.

ORBit avoids clearing buffers as an optimization. Having to look at a flag would sort of defeat this optimization...
I don't think so. You are comparing checking a single integer with clearing a buffer of, I don't know, say, 200 bytes.
No, that's checking an integer vs. nothing.
Of course runtime checking has some overhead. Whether it's negligible or not is another question (it is.)

Alex said that the runtime check sort of defeats the idea of not clearing the buffers in the first place. I don't agree. Clearing the buffers is much heavier than the conditional which when wrapped in G_UNLIKELY will be essentially free.
I looked at the code and I changed my opinion. I remember the code as having scatted one-word ifdefed pad-writes all over the place, but now its just in one place, and it has a runtime check for it already (see giop_send_buffer_init).
Alex, Yes, I saw that check too, but it's not the only place. Check p_memwipe and p_memzero (p_free is irrelevant here.)
Post a Comment

Links to this post:

Create a Link

<< Archive
<< Home