remove obsolete references to code.google.com

I.e. somehow we managed to still point to (very) old gperftools
hosting location, so lets fix it at last.

CMakeLists.txt

@@ -7,7 +7,7 @@ cmake_minimum_required(VERSION 3.12)
 
 project(gperftools VERSION 2.10.0 LANGUAGES C CXX
         DESCRIPTION "Performance tools for C++"
-        HOMEPAGE_URL http://code.google.com/p/gperftools/)
+        HOMEPAGE_URL https://github.com/gperftools/gperftools)
 
 # Update this value for every release!
 set(TCMALLOC_SO_VERSION 9.10.5)

INSTALL

@@ -15,8 +15,9 @@ products checked into it's source repository. This is common practice
 for projects using autotools.
 
 NOTE: Source releases (.tar.gz that you download from
-code.google.com/p/gperftools) still have all required files just as
-before. Nothing has changed w.r.t. building from .tar.gz releases.
+https://github.com/gperftools/gperftools/releases) still have all
+required files just as before. Nothing has changed w.r.t. building
+from .tar.gz releases.
 
 But, in order to build gperftools checked out from subversion
 repository you need to have autoconf, automake and libtool

configure.ac

@@ -576,7 +576,7 @@ AC_DEFINE(PERFTOOLS_DLL_DECL,,
 # the end result is if config.h is #included twice, its #undefs get
 # evaluated twice, but all the ones in mingw.h/etc only get evaluated
 # once, potentially causing trouble.  c.f.
-#   http://code.google.com/p/gperftools/issues/detail?id=246
+#   https://github.com/gperftools/gperftools/issues/248
 AH_TOP([
 #ifndef GPERFTOOLS_CONFIG_H_
 #define GPERFTOOLS_CONFIG_H_

src/debugallocation.cc

@@ -714,7 +714,7 @@ class MallocBlock {
     RAW_LOG(FATAL,
             "Memory was written to after being freed.  MallocBlock: %p, user "
             "ptr: %p, size: %zd.  If you can't find the source of the error, "
-            "try using ASan (http://code.google.com/p/address-sanitizer/), "
+            "try using ASan (https://github.com/google/sanitizers), "
             "Valgrind, or Purify, or study the "
             "output of the deleter's stack printed above.",
             b, b->data_addr(), size);

src/heap-checker.cc

@@ -609,7 +609,7 @@ inline static uintptr_t AsInt(const void* ptr) {
 
 // We've seen reports that strstr causes heap-checker crashes in some
 // libc's (?):
-//    http://code.google.com/p/gperftools/issues/detail?id=263
+//    https://github.com/gperftools/gperftools/issues/265
 // It's simple enough to use our own.  This is not in time-critical code.
 static const char* hc_strstr(const char* s1, const char* s2) {
   const size_t len = strlen(s2);
@@ -2070,7 +2070,7 @@ void HeapLeakChecker_InternalInitStart() {
                    FLAGS_heap_check.c_str());
   }
   // FreeBSD doesn't seem to honor atexit execution order:
-  //    http://code.google.com/p/gperftools/issues/detail?id=375
+  //    https://github.com/gperftools/gperftools/issues/378
   // Since heap-checking before destructors depends on atexit running
   // at the right time, on FreeBSD we always check after, even in the
   // less strict modes.  This just means FreeBSD is always a bit

src/page_heap.cc

@@ -198,7 +198,7 @@ Span* PageHeap::NewLocked(Length n, LockingContext* context) {
     // penalized with higher count of minor page faults.
     //
     // See also large_heap_fragmentation_unittest.cc and
-    // https://code.google.com/p/gperftools/issues/detail?id=368
+    // https://github.com/gperftools/gperftools/issues/371
     ReleaseAtLeastNPages(static_cast<Length>(0x7fffffff));
 
     // then try again. If we are forced to grow heap because of large

src/stacktrace_win32-inl.h

@@ -48,7 +48,7 @@
 // server.
 //
 // This code is inspired by a patch from David Vitek:
-//   http://code.google.com/p/gperftools/issues/detail?id=83
+//   https://github.com/gperftools/gperftools/issues/86
 
 #ifndef BASE_STACKTRACE_WIN32_INL_H_
 #define BASE_STACKTRACE_WIN32_INL_H_

src/tests/large_heap_fragmentation_unittest.cc

@@ -28,7 +28,7 @@
 // This is a unit test for exercising fragmentation of large (over 1
 // meg) page spans. It makes sure that allocations/releases of
 // increasing memory chunks do not blowup memory
-// usage. See also https://code.google.com/p/gperftools/issues/detail?id=368
+// usage. See also https://github.com/gperftools/gperftools/issues/371
 
 
 #include <stddef.h>