You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
339 lines
14 KiB
339 lines
14 KiB
![]()
4 years ago
|
== 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://sparsehash.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!
|