Remove 64-bit unclean line from heap size estimation

src/heap/heap.h

Index: src/heap/heap.h
diff --git a/src/heap/heap.h b/src/heap/heap.h
index c4c806817e4e4eb03b614a0daf6e5b17fa695dfb..678aacfa10ad58775b5448f0304201486f2f4730 100644
--- a/src/heap/heap.h
+++ b/src/heap/heap.h
@@ -1081,7 +1081,10 @@ class Heap {
 
   inline intptr_t PromotedTotalSize() {
     int64_t total = PromotedSpaceSizeOfObjects() + PromotedExternalMemorySize();
-    if (total > kMaxInt) return static_cast<intptr_t>(kMaxInt);
+    if (sizeof(int) < sizeof(int64_t) && total > kMaxInt) {

[Jakob Kummerow, 2015/05/19 14:23:25]

Isn't "sizeof(int) < sizeof(int64_t)" true on all platforms? How about we change
the original line to:

if (total > std::numeric_limits<intptr_t>::max()) {
  return std::numeric_limits<intptr_t>::max();
}

[Sven Panne, 2015/05/19 14:41:46]

Currently, yes (see http://www.unix.org/whitepapers/64bit.html), but there's no
fundamental reason why there can't be an IP64 platform. :-}
Looks OK to me, but I'm really puzzled by all those types used for sizes here
(int, int64_t, intptr_t), this looks really scary and error-prone. Perhaps we
should consistently use (s)size_t or ptrdiff_t? o_O

[Erik Corry Chromium.org, 2015/05/19 15:04:18]

Oh yeah, good point.
Works for me.

[Erik Corry Chromium.org, 2015/05/19 15:04:18]

Yes, see the TODO.  There's no difference between size_t and uintptr_t on any
sensible platform, but on a theoretical segmented platform uintptr_t would be
big enough to hold the size of all objects in all segments, whereas size_t might
only be big enough for the biggest object in one segment.

+      // TODO(erikcorry): Use uintptr_t everywhere we do heap size calculations.
+      return static_cast<intptr_t>(kMaxInt);
+    }
     if (total < 0) return 0;
     return static_cast<intptr_t>(total);
   }