1== 03 February 2012 == 2 3I've just released gperftools 2.0 4 5The `google-perftools` project has been renamed to `gperftools`. I 6(csilvers) am stepping down as maintainer, to be replaced by 7David Chappelle. Welcome to the team, David! David has been an 8an active contributor to perftools in the past -- in fact, he's the 9only person other than me that already has commit status. I am 10pleased to have him take over as maintainer. 11 12I have both renamed the project (the Google Code site renamed a few 13weeks ago), and bumped the major version number up to 2, to reflect 14the new community ownership of the project. Almost all the 15[http://gperftools.googlecode.com/svn/tags/gperftools-2.0/ChangeLog changes] 16are related to the renaming. 17 18The main functional change from google-perftools 1.10 is that 19I've renamed the `google/` include-directory to be `gperftools/` 20instead. New code should `#include <gperftools/tcmalloc.h>`/etc. 21(Most users of perftools don't need any perftools-specific includes at 22all, so this is mostly directed to "power users.") I've kept the old 23names around as forwarding headers to the new, so `#include 24<google/tcmalloc.h>` will continue to work. 25 26(The other functional change which I snuck in is getting rid of some 27bash-isms in one of the unittest driver scripts, so it could run on 28Solaris.) 29 30Note that some internal names still contain the text `google`, such as 31the `google_malloc` internal linker section. I think that's a 32trickier transition, and can happen in a future release (if at all). 33 34 35=== 31 January 2012 === 36 37I've just released perftools 1.10 38 39There is an API-incompatible change: several of the methods in the 40`MallocExtension` class have changed from taking a `void*` to taking a 41`const void*`. You should not be affected by this API change 42unless you've written your own custom malloc extension that derives 43from `MallocExtension`, but since it is a user-visible change, I have 44upped the `.so` version number for this release. 45 46This release focuses on improvements to linux-syscall-support.h, 47including ARM and PPC fixups and general cleanups. I hope this will 48magically fix an array of bugs people have been seeing. 49 50There is also exciting news on the porting front, with support for 51patching win64 assembly contributed by IBM Canada! This is an 52important step -- perhaps the most difficult -- to getting perftools 53to work on 64-bit windows using the patching technique (it doesn't 54affect the libc-modification technique). `premable_patcher_test` has 55been added to help test these changes; it is meant to compile under 56x86_64, and won't work under win32. 57 58For the full list of changes, including improved `HEAP_PROFILE_MMAP` 59support, see the 60[http://gperftools.googlecode.com/svn/tags/google-perftools-1.10/ChangeLog ChangeLog]. 61 62 63=== 24 January 2011 === 64 65The `google-perftools` Google Code page has been renamed to 66`gperftools`, in preparation for the project being renamed to 67`gperftools`. In the coming weeks, I'll be stepping down as 68maintainer for the perftools project, and as part of that Google is 69relinquishing ownership of the project; it will now be entirely 70community run. The name change reflects that shift. The 'g' in 71'gperftools' stands for 'great'. :-) 72 73=== 23 December 2011 === 74 75I've just released perftools 1.9.1 76 77I missed including a file in the tarball, that is needed to compile on 78ARM. If you are not compiling on ARM, or have successfully compiled 79perftools 1.9, there is no need to upgrade. 80 81 82=== 22 December 2011 === 83 84I've just released perftools 1.9 85 86This change has a slew of improvements, from better ARM and freebsd 87support, to improved performance by moving some code outside of locks, 88to better pprof reporting of code with overloaded functions. 89 90The full list of changes is in the 91[http://google-perftools.googlecode.com/svn/tags/google-perftools-1.9/ChangeLog ChangeLog]. 92 93 94=== 26 August 2011 === 95 96I've just released perftools 1.8.3 97 98The star-crossed 1.8 series continues; in 1.8.1, I had accidentally 99removed some code that was needed for FreeBSD. (Without this code 100many apps would crash at startup.) This release re-adds that code. 101If you are not on FreeBSD, or are using FreeBSD with perftools 1.8 or 102earlier, there is no need to upgrade. 103 104=== 11 August 2011 === 105 106I've just released perftools 1.8.2 107 108I was incorrectly calculating the patch-level in the configuration 109step, meaning the TC_VERSION_PATCH #define in tcmalloc.h was wrong. 110Since the testing framework checks for this, it was failing. Now it 111should work again. This time, I was careful to re-run my tests after 112upping the version number. :-) 113 114If you don't care about the TC_VERSION_PATCH #define, there's no 115reason to upgrae. 116 117=== 26 July 2011 === 118 119I've just released perftools 1.8.1 120 121I was missing an #include that caused the build to break under some 122compilers, especially newer gcc's, that wanted it. This only affects 123people who build from source, so only the .tar.gz file is updated from 124perftools 1.8. If you didn't have any problems compiling perftools 1251.8, there's no reason to upgrade. 126 127=== 15 July 2011 === 128 129I've just released perftools 1.8 130 131Of the many changes in this release, a good number pertain to porting. 132I've revamped OS X support to use the malloc-zone framework; it should 133now Just Work to link in tcmalloc, without needing 134`DYLD_FORCE_FLAT_NAMESPACE` or the like. (This is a pretty major 135change, so please feel free to report feedback at 136google-perftools@googlegroups.com.) 64-bit Windows support is also 137improved, as is ARM support, and the hooks are in place to improve 138FreeBSD support as well. 139 140On the other hand, I'm seeing hanging tests on Cygwin. I see the same 141hanging even with (the old) perftools 1.7, so I'm guessing this is 142either a problem specific to my Cygwin installation, or nobody is 143trying to use perftools under Cygwin. If you can reproduce the 144problem, and even better have a solution, you can report it at 145google-perftools@googlegroups.com. 146 147Internal changes include several performance and space-saving tweaks. 148One is user-visible (but in "stealth mode", and otherwise 149undocumented): you can compile with `-DTCMALLOC_SMALL_BUT_SLOW`. In 150this mode, tcmalloc will use less memory overhead, at the cost of 151running (likely not noticeably) slower. 152 153There are many other changes as well, too numerous to recount here, 154but present in the 155[http://google-perftools.googlecode.com/svn/tags/google-perftools-1.8/ChangeLog ChangeLog]. 156 157 158=== 7 February 2011 === 159 160Thanks to endlessr..., who 161[http://code.google.com/p/google-perftools/issues/detail?id=307 identified] 162why some tests were failing under MSVC 10 in release mode. It does not look 163like these failures point toward any problem with tcmalloc itself; rather, the 164problem is with the test, which made some assumptions that broke under the 165some aggressive optimizations used in MSVC 10. I'll fix the test, but in 166the meantime, feel free to use perftools even when compiled under MSVC 16710. 168 169=== 4 February 2011 === 170 171I've just released perftools 1.7 172 173I apologize for the delay since the last release; so many great new 174patches and bugfixes kept coming in (and are still coming in; I also 175apologize to those folks who have to slip until the next release). I 176picked this arbitrary time to make a cut. 177 178Among the many new features in this release is a multi-megabyte 179reduction in the amount of tcmalloc overhead uder x86_64, improved 180performance in the case of contention, and many many bugfixes, 181especially architecture-specific bugfixes. See the 182[http://google-perftools.googlecode.com/svn/tags/google-perftools-1.7/ChangeLog ChangeLog] 183for full details. 184 185One architecture-specific change of note is added comments in the 186[http://google-perftools.googlecode.com/svn/tags/perftools-1.7/README README] 187for using tcmalloc under OS X. I'm trying to get my head around the 188exact behavior of the OS X linker, and hope to have more improvements 189for the next release, but I hope these notes help folks who have been 190having trouble with tcmalloc on OS X. 191 192*Windows users*: I've heard reports that some unittests fail on 193Windows when compiled with MSVC 10 in Release mode. All tests pass in 194Debug mode. I've not heard of any problems with earlier versions of 195MSVC. I don't know if this is a problem with the runtime patching (so 196the static patching discussed in README_windows.txt will still work), 197a problem with perftools more generally, or a bug in MSVC 10. Anyone 198with windows expertise that can debug this, I'd be glad to hear from! 199 200 201=== 5 August 2010 === 202 203I've just released perftools 1.6 204 205This version also has a large number of minor changes, including 206support for `malloc_usable_size()` as a glibc-compatible alias to 207`malloc_size()`, the addition of SVG-based output to `pprof`, and 208experimental support for tcmalloc large pages, which may speed up 209tcmalloc at the cost of greater memory use. To use tcmalloc large 210pages, see the 211[http://google-perftools.googlecode.com/svn/tags/perftools-1.6/INSTALL 212INSTALL file]; for all changes, see the 213[http://google-perftools.googlecode.com/svn/tags/perftools-1.6/ChangeLog 214ChangeLog]. 215 216OS X NOTE: improvements in the profiler unittest have turned up an OS 217X issue: in multithreaded programs, it seems that OS X often delivers 218the profiling signal (from sigitimer()) to the main thread, even when 219it's sleeping, rather than spawned threads that are doing actual work. 220If anyone knows details of how OS X handles SIGPROF events (from 221setitimer) in threaded programs, and has insight into this problem, 222please send mail to google-perftools@googlegroups.com. 223 224To see if you're affected by this, look for profiling time that pprof 225attributes to `___semwait_signal`. This is work being done in other 226threads, that is being attributed to sleeping-time in the main thread. 227 228 229=== 20 January 2010 === 230 231I've just released perftools 1.5 232 233This version has a slew of changes, leading to somewhat faster 234performance and improvements in portability. It adds features like 235`ITIMER_REAL` support to the cpu profiler, and `tc_set_new_mode` to 236mimic the windows function of the same name. Full details are in the 237[http://google-perftools.googlecode.com/svn/tags/perftools-1.5/ChangeLog 238ChangeLog]. 239 240 241=== 11 September 2009 === 242 243I've just released perftools 1.4 244 245The major change this release is the addition of a debugging malloc 246library! If you link with `libtcmalloc_debug.so` instead of 247`libtcmalloc.so` (and likewise for the `minimal` variants) you'll get 248a debugging malloc, which will catch double-frees, writes to freed 249data, `free`/`delete` and `delete`/`delete[]` mismatches, and even 250(optionally) writes past the end of an allocated block. 251 252We plan to do more with this library in the future, including 253supporting it on Windows, and adding the ability to use the debugging 254library with your default malloc in addition to using it with 255tcmalloc. 256 257There are also the usual complement of bug fixes, documented in the 258ChangeLog, and a few minor user-tunable knobs added to components like 259the system allocator. 260 261 262=== 9 June 2009 === 263 264I've just released perftools 1.3 265 266Like 1.2, this has a variety of bug fixes, especially related to the 267Windows build. One of my bugfixes is to undo the weird `ld -r` fix to 268`.a` files that I introduced in perftools 1.2: it caused problems on 269too many platforms. I've reverted back to normal `.a` files. To work 270around the original problem that prompted the `ld -r` fix, I now 271provide `libtcmalloc_and_profiler.a`, for folks who want to link in 272both. 273 274The most interesting API change is that I now not only override 275`malloc`/`free`/etc, I also expose them via a unique set of symbols: 276`tc_malloc`/`tc_free`/etc. This enables clients to write their own 277memory wrappers that use tcmalloc: 278{{{ 279 void* malloc(size_t size) { void* r = tc_malloc(size); Log(r); return r; } 280}}} 281 282 283=== 17 April 2009 === 284 285I've just released perftools 1.2. 286 287This is mostly a bugfix release. The major change is internal: I have 288a new system for creating packages, which allows me to create 64-bit 289packages. (I still don't do that for perftools, because there is 290still no great 64-bit solution, with libunwind still giving problems 291and --disable-frame-pointers not practical in every environment.) 292 293Another interesting change involves Windows: a 294[http://code.google.com/p/google-perftools/issues/detail?id=126 new 295patch] allows users to choose to override malloc/free/etc on Windows 296rather than patching, as is done now. This can be used to create 297custom CRTs. 298 299My fix for this 300[http://groups.google.com/group/google-perftools/browse_thread/thread/1ff9b50043090d9d/a59210c4206f2060?lnk=gst&q=dynamic#a59210c4206f2060 301bug involving static linking] ended up being to make libtcmalloc.a and 302libperftools.a a big .o file, rather than a true `ar` archive. This 303should not yield any problems in practice -- in fact, it should be 304better, since the heap profiler, leak checker, and cpu profiler will 305now all work even with the static libraries -- but if you find it 306does, please file a bug report. 307 308Finally, the profile_handler_unittest provided in the perftools 309testsuite (new in this release) is failing on FreeBSD. The end-to-end 310test that uses the profile-handler is passing, so I suspect the 311problem may be with the test, not the perftools code itself. However, 312I do not know enough about how itimers work on FreeBSD to be able to 313debug it. If you can figure it out, please let me know! 314 315=== 11 March 2009 === 316 317I've just released perftools 1.1! 318 319It has many changes since perftools 1.0 including 320 321 * Faster performance due to dynamically sized thread caches 322 * Better heap-sampling for more realistic profiles 323 * Improved support on Windows (MSVC 7.1 and cygwin) 324 * Better stacktraces in linux (using VDSO) 325 * Many bug fixes and feature requests 326 327Note: if you use the CPU-profiler with applications that fork without 328doing an exec right afterwards, please see the README. Recent testing 329has shown that profiles are unreliable in that case. The problem has 330existed since the first release of perftools. We expect to have a fix 331for perftools 1.2. For more details, see 332[http://code.google.com/p/google-perftools/issues/detail?id=105 issue 105]. 333 334Everyone who uses perftools 1.0 is encouraged to upgrade to perftools 3351.1. If you see any problems with the new release, please file a bug 336report at http://code.google.com/p/google-perftools/issues/list. 337 338Enjoy! 339