Marshal 64 bit byte counts as double through to JavaScript.
As-is, byte counts larger than 31 bits are getting truncated and/or
mis-interpreted as negative numbers, which does no good on the summing.
Also explicitly test the transitions from <31 bit to >31 bit to >32 bits
which I originally suspected of causing the negative aggregates.
BUG=644385
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2881493004
Cr-Commit-Position: refs/heads/master@{#471356}
CrOS-Libchrome-Original-Commit: 03ce267472a3f16830796d5bd04d79371d61afaf
diff --git a/base/tracked_objects_unittest.cc b/base/tracked_objects_unittest.cc
index 80b4064..1eb4199 100644
--- a/base/tracked_objects_unittest.cc
+++ b/base/tracked_objects_unittest.cc
@@ -346,9 +346,23 @@
EXPECT_EQ(data->alloc_overhead_bytes(), 3 * kAllocOverheadBytes);
EXPECT_EQ(data->max_allocated_bytes(), kLargerMaxAllocatedBytes);
- // Saturate everything but aggregate byte counts. The byte counts will be
- // pushed past the 32 bit value range.
+ // Saturate everything but aggregate byte counts.
+ // In the 32 bit implementation, this tests the case where the low-order
+ // word goes negative.
data->RecordAllocations(INT_MAX, INT_MAX, INT_MAX, INT_MAX, INT_MAX, INT_MAX);
+ EXPECT_EQ(data->alloc_ops(), INT_MAX);
+ EXPECT_EQ(data->free_ops(), INT_MAX);
+ // The cumulative byte counts are 64 bit wide, and won't saturate easily.
+ EXPECT_EQ(data->allocated_bytes(),
+ static_cast<int64_t>(INT_MAX) +
+ static_cast<int64_t>(3 * kAllocatedBytes));
+ EXPECT_EQ(data->freed_bytes(),
+ static_cast<int64_t>(INT_MAX) + 3 * kFreedBytes);
+ EXPECT_EQ(data->alloc_overhead_bytes(),
+ static_cast<int64_t>(INT_MAX) + 3 * kAllocOverheadBytes);
+ EXPECT_EQ(data->max_allocated_bytes(), INT_MAX);
+
+ // The byte counts will be pushed past the 32 bit value range.
data->RecordAllocations(INT_MAX, INT_MAX, INT_MAX, INT_MAX, INT_MAX, INT_MAX);
EXPECT_EQ(data->alloc_ops(), INT_MAX);
EXPECT_EQ(data->free_ops(), INT_MAX);