third_party/tcmalloc/vendor/NEWS - src - Git at Google

 == 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!
	== 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!