Adding blink gc memory dump infrastructure for thread specific dumps.

Source/platform/heap/Heap.cpp

Index: Source/platform/heap/Heap.cpp
diff --git a/Source/platform/heap/Heap.cpp b/Source/platform/heap/Heap.cpp
index c938b3a3ffe05e998fc64b37b3048150329650cc..26a92bbcaea0568887fbd99a5f0c7e5d9bb7eaa9 100644
--- a/Source/platform/heap/Heap.cpp
+++ b/Source/platform/heap/Heap.cpp
@@ -41,6 +41,8 @@
 #include "platform/heap/SafePoint.h"
 #include "platform/heap/ThreadState.h"
 #include "public/platform/Platform.h"
+#include "public/platform/WebMemoryAllocatorDump.h"
+#include "public/platform/WebProcessMemoryDump.h"
 #include "wtf/Assertions.h"
 #include "wtf/ContainerAnnotations.h"
 #include "wtf/LeakAnnotations.h"
@@ -213,6 +215,16 @@ void BaseHeap::cleanupPages()
     m_firstPage = nullptr;
 }
 
+void BaseHeap::snapshotMemory(WebProcessMemoryDump* memoryDump, const char* heapName)

[Primiano Tucci (use gerrit), 2015/05/21 09:56:33]

I wonder if we should start calling our functions with dump* instead of
snapshot*, so it will be clear once we have finished which stuff is ours and
which is the old oilpan heap visualizer.
i.e. this could be called dumpMemoryInto

[ssid, 2015/05/21 11:38:55]

Done.

+{
+    String allocatorName = String::format("blink_gc/thread_%p/heaps/%s", threadState(), heapName);

[Primiano Tucci (use gerrit), 2015/05/21 09:56:33]

s/allocatorName/dumpName/

[Primiano Tucci (use gerrit), 2015/05/21 09:56:33]

for the thread name, it would be great if:
1) for the we could have "thread_main" instead of thread_randomnumber if we know
that this is the main thread (see threadState()->isMainThread())
2) We could dump the thread id instead of the object PTR. I think you could use
currentThread() (under the assumption that we are in the right thread).

2 reminds me: can you add a DCHECK(threadState().checkThread()) to check that we
are always dumping on the right thread?

[ssid, 2015/05/21 11:38:55]

done.
done.
Added dcheck to the function in ThreadState.

[ssid, 2015/05/21 11:38:55]

Done.

+    WebMemoryAllocatorDump* allocatorDump = memoryDump->createMemoryAllocatorDump(allocatorName);
+
+    size_t pageCount = 0;
+    for (BasePage* page = m_firstPage; page; page = page->next(), ++pageCount) { }
+    allocatorDump->AddScalar("page_count", "objects", pageCount);

[Primiano Tucci (use gerrit), 2015/05/21 09:56:33]

we have to find a slightly different name here (idea?).
The TL;DR is that these are not "pages" as in system 4k pages, but pretty much
random size "blinkgc" pages

If I am a random engineer and see this column in chrome://tracing I would think
"Ok, this is just using page_count * 4k bytes" which is definitely not true.

+petrcermak can help you find a right name here :)

[ssid, 2015/05/21 16:55:28]

Done.

+}

[Primiano Tucci (use gerrit), 2015/05/21 09:56:33]

some questions here (I guess will be mostly for questions for haraken and team):
- should we skip the count / do something special if page->isEmpty()?
- Should we also add-up the page->size() into a counter (very likely outer_size
for the heap?)
- how do these oilpan "pages" map to "system pages?" are they always multiples
of 4k?
- how is the memory of these pages allocated? Does it always go via mmap (in
which case we are good)? Can be ever be allocated via malloc / partAlloc (in
which case we should add a TODO and keep track of the cross link through the
upcoming graph model)?

[ssid, 2015/05/21 11:38:55]

Empty pages are still taking space in the heap. The next CL plans to give count
of empty, live  and dead pages and their sizes.
These numbers are not easily available and these are planned for next CL. This
CL olny adds page count and sets up infrastructure. If curioud please check how
to get these numbers in the next CL: crrev.com/1149703002
As far as i can see, the pages are allocated by mmap. It uses
WTF::PageAllocator, not PartitionAlloc.
+haraken for answer.

+
 #if ENABLE(ASSERT) || ENABLE(GC_PROFILING)
 BasePage* BaseHeap::findPageFromAddress(Address address)
 {