| == 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 <gperftools/tcmalloc.h>`/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 |
| <google/tcmalloc.h>` 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! |