- Dump Smi objects into the heap profile.

- Dump Smi objects into the heap profile.
Committed: https://code.google.com/p/dart/source/detail?r=17036

[cshapiro, 2013-01-12 02:52:15]

LGTM with comment

Per my note in heap_profiler.cc consider moving and renaming WriteSmiDump.  You
will see what I did with WriteFakeClassDump when you rebase.

[cshapiro, 2013-01-12 02:52:26]

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc
File runtime/vm/heap_profiler.cc (right):

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:127: for (std::set<const RawSmi*>::iterator it =
smi_table_.begin();
You might consider using this idiom...

  for_each(smi_table_.begin(), 
           smi_table_.end(),
           bind1st(mem_fun(&HeapProfiler::WriteSmiDump), this)

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:574: // INSTANCE DUMP - 0x21
We probably do not need to repeat this documentation.

My preference would be to rename this method "WriteSmiInstanceDump" and move it
just below the WriteInstanceDump method.  This is the pattern I followed for the
"Fake" methods I just added (WriteFakeInstanceDump, etc.).

[Ivan Posva, 2013-01-14 23:38:42]

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc
File runtime/vm/heap_profiler.cc (right):

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:574: // INSTANCE DUMP - 0x21
On 2013/01/12 02:52:26, cshapiro wrote:
> We probably do not need to repeat this documentation.
> 
> My preference would be to rename this method "WriteSmiInstanceDump" and move
it
> just below the WriteInstanceDump method.  This is the pattern I followed for
the
> "Fake" methods I just added (WriteFakeInstanceDump, etc.).

Done.

[siva, 2013-01-14 23:50:13]

lgtm

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc
File runtime/vm/heap_profiler.cc (right):

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:586: sub.WriteObjectId(raw_smi);
Since we are writing out smi values as an object id can this potentially collide
with other object ids that we emit out (e.g a class id)

[Ivan Posva, 2013-01-14 23:53:38]

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc
File runtime/vm/heap_profiler.cc (right):

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:586: sub.WriteObjectId(raw_smi);
On 2013/01/14 23:50:13, siva wrote:
> Since we are writing out smi values as an object id can this potentially
collide
> with other object ids that we emit out (e.g a class id)

IDs from the heap profiler dump perspective are the tagged addresses, so we
never get into the VM internal Cid and Smi conflict.

[cshapiro, 2013-01-14 23:55:22]

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc
File runtime/vm/heap_profiler.cc (right):

https://codereview.chromium.org/11881010/diff/1/runtime/vm/heap_profiler.cc#n...
runtime/vm/heap_profiler.cc:586: sub.WriteObjectId(raw_smi);
It should not.  We use an object's address as its it, tag included.  I use some
magic small odd values (small enough that they would fit on page 0) to designate
non-existent classes to keep this convention consistent even when real heap
addresses are unused.