You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/en/docs/guides/diagnostics/memory/using-gc-traces.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -189,7 +189,7 @@ But how could we spot the context?
189
189
190
190
### How to get the context of bad allocations
191
191
192
-
1. Suppose we observe that the old space is continously increasing.
192
+
1. Suppose we observe that the old space is continuously increasing.
193
193
2. Reduce [`--max-old-space-size`][] such that the total heap is closer to the limit
194
194
3. Run the program until you hit the out of memory.
195
195
4. The produced log shows the failing context.
@@ -226,7 +226,7 @@ should be that the last GC trace will contain a bigger heap size.
226
226
[40977:0x128008000] 2066 ms: Mark-sweep (reduce) 99.6 (102.5) -> 99.6 (102.5) MB, 46.7 / 0.0 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 47 ms) (average mu = 0.154, current mu = 0.155) allocati[40977:0x128008000] 2123 ms: Mark-sweep (reduce) 99.6 (102.5) -> 99.6 (102.5) MB, 47.7 / 0.0 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 48 ms) (average mu = 0.165, current mu = 0.175) allocati
227
227
```
228
228
229
-
> Note: In the context of real application, it could be cumbersome to find the leaked object in the code. Heap snpashot could help you to find it. Visit the [guide dedicated to heap snapshot][]
229
+
> Note: In the context of real application, it could be cumbersome to find the leaked object in the code. Heap snapshot could help you to find it. Visit the [guide dedicated to heap snapshot][]
230
230
231
231
### Slowness
232
232
@@ -393,7 +393,7 @@ For more information, you can refer to
0 commit comments