== 3 May 2014 == gperftools 2.2 is out! Here are notable changes since 2.2rc: * issue 620 (crash on windows when c runtime dll is reloaded) was fixed == 19 Apr 2014 == gperftools 2.2rc is out! Here are notable changes since 2.1: * a number of fixes for a number compilers and platforms. Notably Visual Studio 2013, recent mingw with c++ threads and some OSX fixes. * we now have mips and mips64 support! (courtesy of Jovan Zelincevic, Jean Lee, user xiaoyur347 and others) * we now have aarch64 (aka arm64) support! (contributed by Riku Voipio) * there's now support for ppc64-le (by Raphael Moreira Zinsly and Adhemerval Zanella) * there's now some support of uclibc (contributed by user xiaoyur347) * google/ headers will now give you deprecation warning. They are deprecated since 2.0 * there's now new api: tc_malloc_skip_new_handler (ported from chromium fork) * issue-557: added support for dumping heap profile via signal (by Jean Lee) * issue-567: Petr Hosek contributed SysAllocator support for windows * Joonsoo Kim contributed several speedups for central freelist code * TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES environment variable now works * configure scripts are now using AM_MAINTAINER_MODE. It'll only affect folks who modify source from .tar.gz and want automake to automatically rebuild Makefile-s. See automake documentation for that. * issue-586: detect main executable even if PIE is active (based on patch by user themastermind1). Notably, it fixes profiler use with ruby. * there is now support for switching backtrace capturing method at runtime (via TCMALLOC_STACKTRACE_METHOD and TCMALLOC_STACKTRACE_METHOD_VERBOSE environment variables) * there is new backtrace capturing method using -finstrument-functions prologues contributed by user xiaoyur347 * few cases of crashes/deadlocks in profiler were addressed. See (famous) issue-66, issue-547 and issue-579. * issue-464 (memory corruption in debugalloc's realloc after memallign) is now fixed * tcmalloc is now able to release memory back to OS on windows (issue-489). The code was ported from chromium fork (by a number of authors). * Together with issue-489 we ported chromium's "aggressive decommit" mode. In this mode (settable via malloc extension and via environment variable TCMALLOC_AGGRESSIVE_DECOMMIT), free pages are returned back to OS immediately. * MallocExtension::instance() is now faster (based on patch by Adhemerval Zanella) * issue-610 (hangs on windows in multibyte locales) is now fixed The following people helped with ideas or patches (based on git log, some contributions purely in bugtracker might be missing): Andrew C. Morrow, yurivict, Wang YanQing, Thomas Klausner, davide.italiano@10gen.com, Dai MIKURUBE, Joon-Sung Um, Jovan Zelincevic, Jean Lee, Petr Hosek, Ben Avison, drussel, Joonsoo Kim, Hannes Weisbach, xiaoyur347, Riku Voipio, Adhemerval Zanella, Raphael Moreira Zinsly == 30 July 2013 == gperftools 2.1 is out! Just few fixes where merged after rc. Most notably: * Some fixes for debug allocation on POWER/Linux == 20 July 2013 == gperftools 2.1rc is out! As a result of more than a year of contributions we're ready for 2.1 release. But before making that step I'd like to create RC and make sure people have chance to test it. Here are notable changes since 2.0: * fixes for building on newer platforms. Notably, there's now initial support for x32 ABI (--enable-minimal only at this time)) * new getNumericProperty stats for cache sizes * added HEAP_PROFILER_TIME_INTERVAL variable (see documentation) * added environment variable to control heap size (TCMALLOC_HEAP_LIMIT_MB) * added environment variable to disable release of memory back to OS (TCMALLOC_DISABLE_MEMORY_RELEASE) * cpu profiler can now be switched on and off by sending it a signal (specified in CPUPROFILESIGNAL) * (issue 491) fixed race-ful spinlock wake-ups * (issue 496) added some support for fork-ing of process that is using tcmalloc * (issue 368) improved memory fragmentation when large chunks of memory are allocated/freed == 03 February 2012 == I've just released gperftools 2.0 The `google-perftools` project has been renamed to `gperftools`. I (csilvers) am stepping down as maintainer, to be replaced by David Chappelle. Welcome to the team, David! David has been an an active contributor to perftools in the past -- in fact, he's the only person other than me that already has commit status. I am pleased to have him take over as maintainer. I have both renamed the project (the Google Code site renamed a few weeks ago), and bumped the major version number up to 2, to reflect the new community ownership of the project. Almost all the [http://gperftools.googlecode.com/svn/tags/gperftools-2.0/ChangeLog changes] are related to the renaming. The main functional change from google-perftools 1.10 is that I've renamed the `google/` include-directory to be `gperftools/` instead. New code should `#include `/etc. (Most users of perftools don't need any perftools-specific includes at all, so this is mostly directed to "power users.") I've kept the old names around as forwarding headers to the new, so `#include ` will continue to work. (The other functional change which I snuck in is getting rid of some bash-isms in one of the unittest driver scripts, so it could run on Solaris.) Note that some internal names still contain the text `google`, such as the `google_malloc` internal linker section. I think that's a trickier transition, and can happen in a future release (if at all). === 31 January 2012 === I've just released perftools 1.10 There is an API-incompatible change: several of the methods in the `MallocExtension` class have changed from taking a `void*` to taking a `const void*`. You should not be affected by this API change unless you've written your own custom malloc extension that derives from `MallocExtension`, but since it is a user-visible change, I have upped the `.so` version number for this release. This release focuses on improvements to linux-syscall-support.h, including ARM and PPC fixups and general cleanups. I hope this will magically fix an array of bugs people have been seeing. There is also exciting news on the porting front, with support for patching win64 assembly contributed by IBM Canada! This is an important step -- perhaps the most difficult -- to getting perftools to work on 64-bit windows using the patching technique (it doesn't affect the libc-modification technique). `premable_patcher_test` has been added to help test these changes; it is meant to compile under x86_64, and won't work under win32. For the full list of changes, including improved `HEAP_PROFILE_MMAP` support, see the [http://gperftools.googlecode.com/svn/tags/google-perftools-1.10/ChangeLog ChangeLog]. === 24 January 2011 === The `google-perftools` Google Code page has been renamed to `gperftools`, in preparation for the project being renamed to `gperftools`. In the coming weeks, I'll be stepping down as maintainer for the perftools project, and as part of that Google is relinquishing ownership of the project; it will now be entirely community run. The name change reflects that shift. The 'g' in 'gperftools' stands for 'great'. :-) === 23 December 2011 === I've just released perftools 1.9.1 I missed including a file in the tarball, that is needed to compile on ARM. If you are not compiling on ARM, or have successfully compiled perftools 1.9, there is no need to upgrade. === 22 December 2011 === I've just released perftools 1.9 This change has a slew of improvements, from better ARM and freebsd support, to improved performance by moving some code outside of locks, to better pprof reporting of code with overloaded functions. The full list of changes is in the [http://google-perftools.googlecode.com/svn/tags/google-perftools-1.9/ChangeLog ChangeLog]. === 26 August 2011 === I've just released perftools 1.8.3 The star-crossed 1.8 series continues; in 1.8.1, I had accidentally removed some code that was needed for FreeBSD. (Without this code many apps would crash at startup.) This release re-adds that code. If you are not on FreeBSD, or are using FreeBSD with perftools 1.8 or earlier, there is no need to upgrade. === 11 August 2011 === I've just released perftools 1.8.2 I was incorrectly calculating the patch-level in the configuration step, meaning the TC_VERSION_PATCH #define in tcmalloc.h was wrong. Since the testing framework checks for this, it was failing. Now it should work again. This time, I was careful to re-run my tests after upping the version number. :-) If you don't care about the TC_VERSION_PATCH #define, there's no reason to upgrae. === 26 July 2011 === I've just released perftools 1.8.1 I was missing an #include that caused the build to break under some compilers, especially newer gcc's, that wanted it. This only affects people who build from source, so only the .tar.gz file is updated from perftools 1.8. If you didn't have any problems compiling perftools 1.8, there's no reason to upgrade. === 15 July 2011 === I've just released perftools 1.8 Of the many changes in this release, a good number pertain to porting. I've revamped OS X support to use the malloc-zone framework; it should now Just Work to link in tcmalloc, without needing `DYLD_FORCE_FLAT_NAMESPACE` or the like. (This is a pretty major change, so please feel free to report feedback at google-perftools@googlegroups.com.) 64-bit Windows support is also improved, as is ARM support, and the hooks are in place to improve FreeBSD support as well. On the other hand, I'm seeing hanging tests on Cygwin. I see the same hanging even with (the old) perftools 1.7, so I'm guessing this is either a problem specific to my Cygwin installation, or nobody is trying to use perftools under Cygwin. If you can reproduce the problem, and even better have a solution, you can report it at google-perftools@googlegroups.com. Internal changes include several performance and space-saving tweaks. One is user-visible (but in "stealth mode", and otherwise undocumented): you can compile with `-DTCMALLOC_SMALL_BUT_SLOW`. In this mode, tcmalloc will use less memory overhead, at the cost of running (likely not noticeably) slower. There are many other changes as well, too numerous to recount here, but present in the [http://google-perftools.googlecode.com/svn/tags/google-perftools-1.8/ChangeLog ChangeLog]. === 7 February 2011 === Thanks to endlessr..., who [http://code.google.com/p/google-perftools/issues/detail?id=307 identified] why some tests were failing under MSVC 10 in release mode. It does not look like these failures point toward any problem with tcmalloc itself; rather, the problem is with the test, which made some assumptions that broke under the some aggressive optimizations used in MSVC 10. I'll fix the test, but in the meantime, feel free to use perftools even when compiled under MSVC 10. === 4 February 2011 === I've just released perftools 1.7 I apologize for the delay since the last release; so many great new patches and bugfixes kept coming in (and are still coming in; I also apologize to those folks who have to slip until the next release). I picked this arbitrary time to make a cut. Among the many new features in this release is a multi-megabyte reduction in the amount of tcmalloc overhead uder x86_64, improved performance in the case of contention, and many many bugfixes, especially architecture-specific bugfixes. See the [http://google-perftools.googlecode.com/svn/tags/google-perftools-1.7/ChangeLog ChangeLog] for full details. One architecture-specific change of note is added comments in the [http://google-perftools.googlecode.com/svn/tags/perftools-1.7/README README] for using tcmalloc under OS X. I'm trying to get my head around the exact behavior of the OS X linker, and hope to have more improvements for the next release, but I hope these notes help folks who have been having trouble with tcmalloc on OS X. *Windows users*: I've heard reports that some unittests fail on Windows when compiled with MSVC 10 in Release mode. All tests pass in Debug mode. I've not heard of any problems with earlier versions of MSVC. I don't know if this is a problem with the runtime patching (so the static patching discussed in README_windows.txt will still work), a problem with perftools more generally, or a bug in MSVC 10. Anyone with windows expertise that can debug this, I'd be glad to hear from! === 5 August 2010 === I've just released perftools 1.6 This version also has a large number of minor changes, including support for `malloc_usable_size()` as a glibc-compatible alias to `malloc_size()`, the addition of SVG-based output to `pprof`, and experimental support for tcmalloc large pages, which may speed up tcmalloc at the cost of greater memory use. To use tcmalloc large pages, see the [http://google-perftools.googlecode.com/svn/tags/perftools-1.6/INSTALL INSTALL file]; for all changes, see the [http://google-perftools.googlecode.com/svn/tags/perftools-1.6/ChangeLog ChangeLog]. OS X NOTE: improvements in the profiler unittest have turned up an OS X issue: in multithreaded programs, it seems that OS X often delivers the profiling signal (from sigitimer()) to the main thread, even when it's sleeping, rather than spawned threads that are doing actual work. If anyone knows details of how OS X handles SIGPROF events (from setitimer) in threaded programs, and has insight into this problem, please send mail to google-perftools@googlegroups.com. To see if you're affected by this, look for profiling time that pprof attributes to `___semwait_signal`. This is work being done in other threads, that is being attributed to sleeping-time in the main thread. === 20 January 2010 === I've just released perftools 1.5 This version has a slew of changes, leading to somewhat faster performance and improvements in portability. It adds features like `ITIMER_REAL` support to the cpu profiler, and `tc_set_new_mode` to mimic the windows function of the same name. Full details are in the [http://google-perftools.googlecode.com/svn/tags/perftools-1.5/ChangeLog ChangeLog]. === 11 September 2009 === I've just released perftools 1.4 The major change this release is the addition of a debugging malloc library! If you link with `libtcmalloc_debug.so` instead of `libtcmalloc.so` (and likewise for the `minimal` variants) you'll get a debugging malloc, which will catch double-frees, writes to freed data, `free`/`delete` and `delete`/`delete[]` mismatches, and even (optionally) writes past the end of an allocated block. We plan to do more with this library in the future, including supporting it on Windows, and adding the ability to use the debugging library with your default malloc in addition to using it with tcmalloc. There are also the usual complement of bug fixes, documented in the ChangeLog, and a few minor user-tunable knobs added to components like the system allocator. === 9 June 2009 === I've just released perftools 1.3 Like 1.2, this has a variety of bug fixes, especially related to the Windows build. One of my bugfixes is to undo the weird `ld -r` fix to `.a` files that I introduced in perftools 1.2: it caused problems on too many platforms. I've reverted back to normal `.a` files. To work around the original problem that prompted the `ld -r` fix, I now provide `libtcmalloc_and_profiler.a`, for folks who want to link in both. The most interesting API change is that I now not only override `malloc`/`free`/etc, I also expose them via a unique set of symbols: `tc_malloc`/`tc_free`/etc. This enables clients to write their own memory wrappers that use tcmalloc: {{{ void* malloc(size_t size) { void* r = tc_malloc(size); Log(r); return r; } }}} === 17 April 2009 === I've just released perftools 1.2. This is mostly a bugfix release. The major change is internal: I have a new system for creating packages, which allows me to create 64-bit packages. (I still don't do that for perftools, because there is still no great 64-bit solution, with libunwind still giving problems and --disable-frame-pointers not practical in every environment.) Another interesting change involves Windows: a [http://code.google.com/p/google-perftools/issues/detail?id=126 new patch] allows users to choose to override malloc/free/etc on Windows rather than patching, as is done now. This can be used to create custom CRTs. My fix for this [http://groups.google.com/group/google-perftools/browse_thread/thread/1ff9b50043090d9d/a59210c4206f2060?lnk=gst&q=dynamic#a59210c4206f2060 bug involving static linking] ended up being to make libtcmalloc.a and libperftools.a a big .o file, rather than a true `ar` archive. This should not yield any problems in practice -- in fact, it should be better, since the heap profiler, leak checker, and cpu profiler will now all work even with the static libraries -- but if you find it does, please file a bug report. Finally, the profile_handler_unittest provided in the perftools testsuite (new in this release) is failing on FreeBSD. The end-to-end test that uses the profile-handler is passing, so I suspect the problem may be with the test, not the perftools code itself. However, I do not know enough about how itimers work on FreeBSD to be able to debug it. If you can figure it out, please let me know! === 11 March 2009 === I've just released perftools 1.1! It has many changes since perftools 1.0 including * Faster performance due to dynamically sized thread caches * Better heap-sampling for more realistic profiles * Improved support on Windows (MSVC 7.1 and cygwin) * Better stacktraces in linux (using VDSO) * Many bug fixes and feature requests Note: if you use the CPU-profiler with applications that fork without doing an exec right afterwards, please see the README. Recent testing has shown that profiles are unreliable in that case. The problem has existed since the first release of perftools. We expect to have a fix for perftools 1.2. For more details, see [http://code.google.com/p/google-perftools/issues/detail?id=105 issue 105]. Everyone who uses perftools 1.0 is encouraged to upgrade to perftools 1.1. If you see any problems with the new release, please file a bug report at http://code.google.com/p/google-perftools/issues/list. Enjoy!