guide: apply review suggestions

locale/en/docs/guides/diagnostics/index.md

@@ -9,7 +9,7 @@ These guides were created in the [Diagnostics Working Group](https://github.com/
 with the objective to provide a guidance when diagnosing an issue
 in the user application.
 The documentation project is organized based on user journey.
-Those journeys are coherent set of step-by-step procedures,
+Those journeys are a coherent set of step-by-step procedures,
 that a user follows for problem determination of reported issues.
 
 This is the available set of diagnostics guides:

locale/en/docs/guides/diagnostics/memory/index.md

@@ -36,7 +36,8 @@ restarts make certain requests to fail _(load balancer responds with 502)_.
 * Process restarts due to the memory exhaustion and request are dropped on the
   floor
 * Increased GC activity leads to higher CPU usage and slower response time
-* Increased memory swapping slows down the process
+  * GC blocking the Event Loop causing slowness
+* Increased memory swapping slows down the process (GC activity)
 * May not have enough available memory to get a Heap Snapshot
 
 ### Debugging

locale/en/docs/guides/diagnostics/memory/using-gc-traces.md

@@ -8,7 +8,8 @@ layout: docs.hbs
 There's a lot to learn about how the garbage collector works, but if you learn
 one thing it's that when GC is running, your code is not.
 
-You may want to know how often and how long the garbage collection is running.
+You may want to know how often and how long the garbage collection is running,
+and what is the outcome.
 
 ## Runnig with garbage collection traces
 
@@ -20,7 +21,8 @@ $ node --trace_gc app.js
 ```
 
 You might want to avoid getting traces from the entire lifetime of your
-process running on a server. In that case, set the flag from within the process.
+process running on a server. In that case, set the flag from within the process,
+and switch it off once the need for tracing is over.
 
 Here's how to print GC events to stdout for one minute.
 
@@ -92,7 +94,7 @@ This is how to interpret the trace data (for the second line):
 
 ## Using performance hooks to trace garbage collection
 
-For Node.js v8.5.0 or later, you can use [performance hooks][] to trace
+In Node.js, you can use [performance hooks][] to trace
 garbage collection.
 
 ```js
@@ -177,7 +179,7 @@ For more information, you can refer to
 
 A. How to get context of bad allocations
 1. Suppose we observe that the old space is continously increasing.
-2. But due to heavy gc, the heap roof is not hit, but the process is slow.
+2. But due to heavy gc, the heap maximum is not hit, but the process is slow.
 3. Review the trace data and figure out how much is the total heap before and
 after the gc.
 4. Reduce `--max-old-space-size` such that the total heap is closer to the
@@ -187,7 +189,7 @@ limit.
 
 B. How to assert whether there is a memory leak when heap growth is observed
 1. Suppose we observe that the old space is continously increasing.
-2. Due to heavy gc, the heap roof is not hit, but the process is slow.
+2. Due to heavy gc, the heap maximum is not hit, but the process is slow.
 3. Review the trace data and figure out how much is the total heap before and
 after the gc.
 4. Reduce `--max-old-space-size` such that the total heap is closer to the
@@ -196,7 +198,7 @@ limit.
 6. If it hits OOM, increment the heap size by ~10% or so and repeat few times.
 If the same pattern is observed, it is indicative of a memory leak.
 7. If there is no OOM, then freeze the heap size to that value - A packed heap
-reduces memory footprint and compation latency.
+reduces memory footprint and compaction latency.
 
 C. How to assert whether too many gcs are happening or too many gcs are causing
 an overhead

locale/en/docs/guides/diagnostics/memory/using-heap-profiler.md

@@ -38,7 +38,7 @@ node --inspect index.js
 
 > `--inspect-brk` is an better choice for scripts.
 
-Connect to the dev-tools instance and then:
+Connect to the dev-tools instance in chrome and then:
 
 * Select `memory` tab
 * Select `Allocation instrumentation timeline`

locale/en/docs/guides/diagnostics/memory/using-heap-snapshot.md

@@ -6,12 +6,12 @@ layout: docs.hbs
 # Using Heap Snapshot
 
 You can take a Heap Snapshot from your running application and load it into
-Chrome Developer Tools to inspect certain variables or check retainer size.
+[Chrome Developer Tools][] to inspect certain variables or check retainer size.
 You can also compare multiple snapshots to see differences over time.
 
 ## Warning
 
-To create a snapshot, all other work in your main thread is stopped.
+When creating a snapshot, all other work in your main thread is stopped.
 Depending on the heap contents it could even take more than a minute.
 The snapshot is built in memory, so it can double the heap size, resulting
 in filling up entire memory and then crashing the app.
@@ -158,3 +158,4 @@ Practice capturing heap snapshots and finding memory leaks with
 [load button image]: /static/images/docs/guides/diagnostics/load-snapshot.png
 [comparison image]: /static/images/docs/guides/diagnostics/compare.png
 [heapsnapshot exercise]: https://github.com/naugtur/node-example-heapdump
+[Chrome Developer Tools]: https://developer.chrome.com/docs/devtools/