Add tool to help analyze binary size

tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java

Index: tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java
diff --git a/tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java b/tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java
new file mode 100644
index 0000000000000000000000000000000000000000..2552a9e4d0605b9a0d5452bfb3c4ffccd8340b78
--- /dev/null
+++ b/tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java
@@ -0,0 +1,19 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+package org.chromium.tools.binary_size;
+
+/**
+ * A record that is filled in partially by nm and partially by addr2line,
+ * along with tracking information about whether or not the lookup in
+ * addr2line was successful. All fields are volatile because this structure

[bulach, 2014/01/07 19:38:30]

hmm... is it ever used concurrently? just the fact that it's passed across
threads doesn't justify volatile, no?

[Andrew Hayden (chromium.org), 2014/01/08 00:56:45]

It is written in two separate threads and read in a third, so yes, it needs to
be volatile. Some fields could probably be final, but the long pole here is
addr2line so I'm not too worried about the performance implications of reading
and writing these.

+ * is passed amongst threads.
+ */
+class Record {
+    volatile String address;
+    volatile char symbolType;
+    volatile String symbolName;
+    volatile String size;
+    volatile String location;
+    volatile boolean resolvedSuccessfully;
+}