feedback

Author: Maoni0

docs/core/runtime-config/garbage-collector.md

@@ -574,7 +574,7 @@ If the per heap hard limits are set, the reserve range is the same as the total
 
 This range is limited by the amount of total virtual memory. Normally on 64-bit this is never a problem, but there could be a virtual memory limit set on a process. This range is limited by half that amount. For example, if you set the `HeapHardLimit` config to 1 GB and have a 4 GB virtual memory limit set on the process, this range is `min (5x1GB, 4GB/2)`, which is 2 GB.
 
-You can use the `GC.GetConfigurationVariables` API to see the value of this range under the name `GCRegionRange`. If you do get `E_OUTOFMEMORY` during the runtime intialization and want to see if it's due to reserving this range, you can look at the `VirtualAlloc`call with `MEM_RESERVE` on Windows and the `mmap` call with `PROT_NONE` on Linux during GC initialization and see if the OOM is from that call. If this reserve call is failing, you can change it via the following configuration settings.
+You can use the `GC.GetConfigurationVariables` API to see the value of this range under the name `GCRegionRange`. If you do get `E_OUTOFMEMORY` during the runtime intialization and want to see if it's due to reserving this range, you can look at the `VirtualAlloc`call with `MEM_RESERVE` on Windows and the `mmap` call with `PROT_NONE` on Linux during GC initialization and see if the OOM is from that call. If this reserve call is failing, you can change it via the following configuration settings. The recommendation for the reservation amount is two to five times the committed size for your GC heap. If your scenario does not make many large allocations (this could be any allocations on UOH or larger than the UOH region size), twice the committed size should be quite safe. Otherwise you might want to make it larger so you don't incur too frequent full compacting GCs to make space for those larger regions.
 
 | | Setting name | Values | Version introduced |
 | - | - | - | - |