Add answer for header of heap dump

Author: Benoit Tigeot

README.md

@@ -12,9 +12,9 @@ Here is a list of questions I have. Feel free to make a PR to answer them.
 
 * Retained Vs Allocated: Does an object that is allocated can turn to be retained because he is still present after few GC ?
 
-* What are the first line of a heap dump that are not address ?
+* **[Answered]** What are the first line of a heap dump that are not address ?
 
-  header of the heap dump [from heapy gem](https://github.com/schneems/heapy/tree/master/spec/fixtures/dumps) (carefull is 78mo text file)
+  Header of the heap dump [from heapy gem](https://github.com/schneems/heapy/tree/master/spec/fixtures/dumps) (carefull is 78mo text file)
 
    ```ruby
   {"type":"ROOT", "root":"vm", "references":["0x7fb4740bc400", "0x7fb4740b79a0", "0x7fb4740dff68", "0x7fb4740bff60", "0x7fb4740bff10", "0x7fb474c13a88", "0x7fb474ac0618", "0x7fb4740bfe98", "0x7fb4740bfe70", "0x7fb4740ddc68", "0x7fb4740dff90", "0x7fb4772f88d8", "0x7fb4772f8900"]}
@@ -23,8 +23,47 @@ Here is a list of questions I have. Feel free to make a PR to answer them.
   {"type":"ROOT", "root":"global_list", "references":["0x7fb4759d3678", "0x7fb4759d3768", "0x7fb4759d3790", "0x7fb4759d37e0", "0x7fb4759d3808", "0x7fb4759d3830", "0x7fb4759d38d0", "0x7fb4759d3920", "0x7fb4759d3970", "0x7fb4759d3998", "0x7fb4759d39e8", "0x7fb4759d3a10", "0x7fb4759d3a38", "0x7fb4759d3a88", "0x7fb4759d3ab0", "0x7fb4759d3ad8", "0x7fb4759d3b00", "0x7fb4759d3b28", "0x7fb4759d3b78", "0x7fb4759d3ba0", "0x7fb4759d3bc8", "0x7fb4759d3bf0", "0x7fb4759d3c18", "0x7fb4759d3c40", "0x7fb4759d3c68", "0x7fb4759d3c90", "0x7fb4759d3cb8", "0x7fb4759d3ce0", "0x7fb4759d3d58", "0x7fb4759d3dd0", "0x7fb4759d3df8", "0x7fb4759d3e20", "0x7fb4759d3e70", "0x7fb4759d3ee8", "0x7fb4759d3f10", "0x7fb4759d3fb0", "0x7fb474135fa8", "0x7fb4741353c8", "0x7fb474134270", "0x7fb474134298", "0x7fb4741342c0", "0x7fb4741342e8", "0x7fb474134310", "0x7fb474134338", "0x7fb474134360", "0x7fb474134388", "0x7fb4741343b0", "0x7fb4741343d8", "0x7fb474134428", "0x7fb474134450", "0x7fb474134478", "0x7fb4741344a0", "0x7fb4741344c8", "0x7fb4741344f0", "0x7fb474134518", "0x7fb474134540", "0x7fb474134568", "0x7fb474134590", "0x7fb474134608", "0x7fb47481da50", "0x7fb47481dac8", "0x7fb47481db40", "0x7fb47481db68", "0x7fb47481dd20", "0x7fb47481dd98", "0x7fb47481dfa0", "0x7fb47481dfc8", "0x7fb47481e018", "0x7fb47481e040", "0x7fb47481e248", "0x7fb47481e388", "0x7fb47481e5e0", "0x7fb47481e608", "0x7fb47481e6a8", "0x7fb47481e770", "0x7fb47481e7e8", "0x7fb47481e8d8", "0x7fb47481e928", "0x7fb47481e9c8", "0x7fb47481ea40", "0x7fb47481eae0", "0x7fb47481ec48", "0x7fb47481ed88", "0x7fb47481ee28", "0x7fb47481ee50", "0x7fb47481f058", "0x7fb47481f0d0", "0x7fb47481f0f8", "0x7fb47481f210", "0x7fb47481f288", "0x7fb47481f378", "0x7fb47481f418", "0x7fb47481f440", "0x7fb47481f4b8", "0x7fb47481f508", "0x7fb47481f710", "0x7fb47481f738", "0x7fb47481f760", "0x7fb47481fad0", "0x7fb47481fb20", "0x7fb47481fb70", "0x7fb47481fbe8", "0x7fb47584f270", "0x7fb475874700", "0x7fb475874a20", "0x7fb4769904d0", "0x7fb4740dff40"]}
   ```
 
+  **Answered by Aaron Patterson https://github.com/benoittgt/understand_ruby_memory/issues/1**
 
-  Partially answered from https://blog.codeship.com/the-definitive-guide-to-ruby-heap-dumps-part-i/ but not the header.
+  > Those are "ROOTS" (the ones with type = "ROOTS").  The system has various "roots".
+
+  > #### What is a "ROOT"?
+
+  > Objects in the system form a tree data structure.  Imagine some code like this:
+
+  ```ruby
+  a = "foo"
+  b = "bar"
+  c = { a => b }
+  ```
+
+  > It's easy to see how `c` is connected to `a` and `b` and prevents them from being garbage collected:
+
+  ![abc](http://imgur.com/Rcc08c2.png)
+
+  > But say we have this:
+
+  ```ruby
+  a = "foo"
+  b = "bar"
+  c = { a => b }
+  GC.start
+  p c
+  ```
+
+  > What prevents `c` from being garbage collected?  Something must hold a reference to `c` so that the garbage collector can know that it shouldn't be GC'd.  This is where ROOTS come in.  Roots are special nodes in the system that hold on to these references:
+
+  ![roots](http://imgur.com/5OhGzvI.png)
+
+  > MRI has a few different places it considers a root, and those are in the name `root` (like `vm`, `finalizers`, etc).  Explaining each of these types is a little too long for here, but you can think of them as the root of the tree that forms your object graph.  They keep your program objects alive, and they are the starting point for the GC to find live objects in your system.  In fact the graph I showed above is a little inaccurate.  Since `a` and `b` are also top level local variables like `c`, the graph looks a bit more like this:
+
+  ![total](http://imgur.com/P7JFgN8.png)
+
+  > Hope that helps!
+
+-----
+
+  For the rest of the dump. Go to https://blog.codeship.com/the-definitive-guide-to-ruby-heap-dumps-part-i/ but not the header.
 
   > Manually inspecting this file might be of some interest, but we really need to aggregate information to make use of this data. Before we do that, let’s look at some of the keys in the generated JSON.
   > * generation: The garbage collection generation where the object was generated
@@ -35,7 +74,7 @@ Here is a list of questions I have. Feel free to make a PR to answer them.
   > * references: The memory addresses of other objects that this object retains
   > There are other keys, but that’s enough for now. It’s worth noting that several of these are optional. For example if an object was generated before you started tracing object allocations, it won’t contain generation, file, or line information.
 
-* What is allocated and what is not allocated ([*Not every object requires allocation*](https://youtu.be/gtQmWk8mCRs?list=PLXvaGTBVk36uIVBGKI72vqd9BFcMmPFI7&t=1869))?
+* **[Partially answered]**j w What is allocated and what is not allocated ([*Not every object requires allocation*](https://youtu.be/gtQmWk8mCRs?list=PLXvaGTBVk36uIVBGKI72vqd9BFcMmPFI7&t=1869))?
 
   The list is a mix of "types" that may be not clear enough