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..c36735efed9fa67d994a3a0f8f580495e08bbd72
--- /dev/null
+++ b/tools/binary_size/java/src/org/chromium/tools/binary_size/Record.java
@@ -0,0 +1,18 @@
+// 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.
+ */
+class Record {
+    String address;

[bulach, 2014/01/08 15:04:00]

yeah, so just to close the loop re: volatile...

beyond torne's explanation, it'd be used when the values are actually being
accessed concurrently, so that the compiler would make all the reads (and
writes) go through memory rather than cached in a CPU register or something... 
the simplest example I can remember is something like "while (!stopped) do()" in
thread X, and another thread Y do "stopped = true"...

compilers (and VMs) are free to optimize reading the "stopped" value just once,
since it knows nothing else will change its value... by adding the "volatile",
it'll force to always access the memory to get its value....

it's obviously far more subtle, but this is the "take your grain of salt"
explanation.. ;)

(another use for volatile is for shared memory... say, device drivers with DMA
can manipulate areas of memory that are also manipulated directly by the
device... in which case, it's never safe to "cache" said value in a CPU
register, all access have to through the actual memory..)

anyways... in this case, Records are being created (i.e., written) in one
thread, then put in the hashmap, and then much later on are being read and
dumped in another thread, so there's no need to mark as volatile...

[Andrew Hayden (chromium.org), 2014/01/08 21:04:10]

Thanks. I am fairly familiar with the Java Memory Model and the concepts of
memory fences and all that good jazz. I missed the point that torne@ had made
about using queues to pass them around, which is totally correct; since all the
modifications that I need to see happen-before any of the actual reads, it's
accurate that there is no need for volatile here.

Your explanation is, for the record, very well written :)

+    char symbolType;
+    String symbolName;
+    String size;
+    String location;
+    boolean resolvedSuccessfully;
+}